On Sat, May 14, 2022 at 10:22 PM Matías Fonzo <selk@dragora.org> 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 <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.
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