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 <dfgdust@gmail.com> wrote:
>>>
>>> On Fri, May 13, 2022 at 10:18 PM Matias Fonzo <selk@dragora.org>
>>> 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.
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.
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
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)
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...