Re: [Dragora-users] Proposal: flexible script to create different images

[DustDFG]

On Mon, Aug 1, 2022 at 7:50 PM Matías Fonzo <selk@dragora.org> wrote:
>
>
> Sorry, I had not seen this email before.
>
> What is it about?
>

It is about splitting stage. The commit [1] split the stage 1 for two
stages. The commit description explains how. So the stage one can be a
base for temporary sytem that on stage 2 adds build programs or for
the minimal system where we can add qire and other programs if needed

[1] 
https://notabug.org/dustdfg/dragora/commit/bd11424884cb2337294b8a42e4d4e1e2443a9845

> El 2022-07-16 11:27, DustDFG escribió:
> > 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.
> >>
> >> 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...
> >>
> >>
> >
> > Hello Matias!
> >
> > The stage 1 from this commit [1] can be a base for minimal system and
> > temporary system at the same time. What do you think about it?
> >
> > [1]
> > https://notabug.org/dustdfg/dragora/commit/bd11424884cb2337294b8a42e4d4e1e2443a9845
>