On Sat, May 14, 2022 at 10:22 PM Matías Fonzo <[email protected]> wrote: > > El 2022-05-14 17:05, Matías Fonzo escribió: > > El 2022-05-14 10:05, DustDFG escribió: > >> On Sat, May 14, 2022 at 6:08 AM DustDFG <[email protected]> wrote: > >>> > >>> On Fri, May 13, 2022 at 10:18 PM Matias Fonzo <[email protected]> > >>> wrote: > >>> > > >>> > El 2022-05-13 13:51, DustDFG escribió: > >>> > > >>> I also think that we can make an exception for kernel category and > >>> not > >>> to change it. So we will get essential category that contains > >>> everything for the minimal system except the kernel. It is obvious > >>> that system needs kernel for running so it isn't so necessary to > >>> point > >>> out it. In this case, hypothetical essential.order file will process > >>> only packages from these two categories and it looks logical. What do > >>> you think about it? What do you like more (subcategory or exception > >>> for kernel category or maybe something else)? > > > > We have to try to keep things simple, this is also subject to how you > look at it. > > The discussion has two aspects, the build side and the part of the > already running system, which delivers the packages, let's call it the > binary side. > > If I understand correctly what you want or propose to offer from the > build side is the essential or minimum for the system to run, instead of > having to build all or the rest of the series. This I assume would be > for the purpose of wanting to have a minimal system for the purpose of > saving time or resources on the build side. Here we are pointedly > referring to the final build of the system from within the temporary > system. >
You created an idea with essential order and essential category. I liked it because it looks to me that it can improve semantic and split fat "00-core.order" file to two parts. I think that this idea is very good even if it won't be used as part of build system... > If you create a new series called e.g. "00-essential.order" where you > have the essential packages annotated, you must have add or annotate the > recipes that belong to the build software (musl, binutils, gcc, ...), as > the system has to be adjusted to its final paths. By this is meant > assuming that the minimal system is built in its entirety, this leaves > the build packages installed as well. In this whole stage of building > the "essential" series from this point on, it translates into time, > build time to build and install the packages that build software, plus > the packages required to run the system. While it is true that you can > later remove the build packages to leave only what is required, it is > time consuming to want to build it. > I thought about "00-essential.order" as minimal list of packages (without the build software). The list of what you want to provide for the M stage is the list of what I want to move to this order file. > On the other hand, it would be smarter to take advantage of what we > already have, and that is that the build tools are built at an early > stage (stage 0), and if there is a new stage, where you aim for a small > system as much as possible, where you offer the possibility to install > binary packages, then I think that would be better. It saves resources > and time, specifically it saves this: > > ./bootstrap -s0 && ./bootstrap -s1 && ./enter-chroot && qi build > order /usr/src/qi/recipes/00-essential.order | qi build -S -p -i - 2>&1 > | tee /essential-log.txt > Yes, I thought about command like it. I want to point out that if we won't use the "00-essential.order" as part of the build system it will be better to have it. I think that "00-core.order" is a little fat now. The "00-essential.order" file can improve semantic and cut big "00-core.order" file even without "essential" category > When it could be done as: > > ./bootstrap -s0 && ./bootstrap -sM > > By the way, the "./bootstrap -s0" instruction can be avoided, if you > unpack a flavour offered by Darkcrusade, by unpacking one of the > (pre-made) cross-compilers under the "OUTPUT.bootstrap" directory. > > Then, the "M" stage which is a challenge, a challenge in the sense that > it contains only what is necessary for system execution, for example: > > M/01-kernel > M/02-musl > M/03-busybox > M/04-sysvinit > M/05-bootscripts > M/06-perl (perl-cross here) > M/07-graft > M/08-lzlib > M/09-tarlz > M/10-plzip > M/11-qi > M/12-qire (and its dependencies for remote package installation) > Qi also needs (almost) all packages from the "compressors" category [1] > The challenge is also to have the minimum as well as the "just enough" > configurations of what the system needs, which is intended to leave it > running so that it can be extended, through the binary packages > provided. > > (I mention or write all this for the record, in case it is done > tomorrow). > > Now, from the binary side, and related to the build, if we mark those > essential packages (not those essential to build) but those essential > for the execution of the system, then we could offer the installation of > the "minimal" system from the dragora-installer... > > I wanted to do it with "00-essential.order" [1] https://lists.nongnu.org/archive/html/dragora-users/2022-05/msg00018.html
