merge plans about minimal HOT 9 CLOSED

Short answer - yes, merging your work in MLL will be great!

Long answer - I'm currently thinking of a way to simplify the build structure. As you can see, currently there is one main "flat" folder and tons of scripts there. If you compare this structure with the first version of MLL it's easy to notice that the current build process is way more advanced/productive/optimized/improved and it is also way more complex.

Since there is no tight schedule, nor I have any particular plans when to release the next "official" MLL version, it's perfectly OK to merge your work in MLL and then I can continue with the architectural reorganization process.

from minimal.

@ivandavidov I've actually seen this problem of the simplification of the MLL Build Script, and if you go to the 'rewrite' branch of my project 'AwlsomeLinux' you can see that I have reduced it to three scripts, one for the Core Creation, one for the Image Creation, and one for the Overlay Creation. If you want I can apply this to my fork of 'Minimal' and I can create a pull request.

from minimal.

Regarding architecture, having sub folders for each tasks would make sense. then you can run the scripts with run-parts(8) instead of having it being called explicitly in another script.
I dont think that merging it into even bigger scripts (the iso creating is huge for example) is a good idea.

from minimal.

Yeah I agree with that @K1773R Besides the simplified version that I created is VERY self-centered, but one thing that you could also do is define functions in the script. For example, in the Image script, src_pack() {code here} is defined and at the bottom of the script src_pack is called. But of course this would make the script huge, but not very complicated.

from minimal.

@AwlsomeAlex - I appreciate your enthusiasm but I'll ask you to hold off with such major pull requests. As K1773R already mentioned, writing even longer scripts is not the right solution here. One drawback of such approach is that instead of loose coupling you introduce tight coupling which is harder to maintain in the long run.

@K1773R - thank you for the run-parts hint. I didn't know about it. :)

In a perfect world full of unicorns, what I'd like to have in MLL is only one shell script (probably the one which wraps all other script executions) and just one folder which holds the initramfs structure, the overlay bundle scripts, etc. This folder in turn has to have quite simple file/folder structure. After all, the main goal of MLL is to be an educational project (simpler than Linux From Scratch), so everything in MLL must be simple to understand and even simpler to follow.

from minimal.

@K1773R - considering the current script mess and the fact that I don't spend much time on this project, I don't think that merging your work will do any good. At least not at this point.

Here is my grand plan at the moment:

1. Structural reorganization - find better project structure where the flat folder full of scripts is organized better.
2. No more new features or enhancements, except for version bumps and bug fixes (if the reported issue is indeed a bug).
3. Release the current state of the project (with updated project structure) as new MLL version. Some features are not complete (e.g. the installer is not EFI-ready, there is no multi-arch support in 64-bit mode, etc.) but these features are all part of the 'overlay' functionality and they will be available to the general audience without support or warranty of any kind.
4. Think of a way to incorporate other flavors of MLL in the same project. So far there is your PowerPC MLL version and my unofficial AArch64 MLL for Odroid-C2 (not in this repository). However, currently both forks use architecture specific stuff and even though these differences can be isolated in separate script files, the overall MLL project structure has to be very well planned in advance to provide before/after' callbacks' and provide way to 'override' certain script in favor of another script. Once this infrastructure is in place, this should allow the possibility to use the MLL build infrastructure and provide additional scripts (or perhaps override some of the existing scripts) which should be used for other CPU architectures.

I have no specific time frames or anything else in mind. I hope I'll have more free time to work on MLL soon!

from minimal.

Feel free to reorganize anytime. Just keep multi architecture in mind, so i can add/do the powerpc part when done. Notify me when you need some ideas about organizing it and when i should work on my part of the project :)

from minimal.

For now I was able to refactor the overlay functionality in separate build subsystem which is more or less independent from the base build system. I'm open for suggestions how to reorganize the base scripts in such way that we could have both easy differentiation between architectures (e.g. perhaps a folder per architecture) and script separation between architectures (e.g. no need for clever if conditions in the base scripts in order to split the logic between different architecture branches).

Another problem - we have not only scripts here, but also configurations and additional folders (e.g. the initramfs/rootfs folder) and depending on the architecture that we build, changes may be required on all these places.

from minimal.

@K1773R - I'll close this issue since I haven't come up with any reasonable way to merge your work and keep the simplicity of the associated build processes at the same time.

I'm open for suggestions and if you come up with architectural solution which works fine, I'll be glad to integrate the proposed solution.

from minimal.