Hello DustDFG!,
El 2022-05-10 14:29, DustDFG escribió:
>
> On Tue, May 10, 2022 at 1:47 PM Matias Fonzo <selk@dragora.org> wrote:
>
>> El 2022-05-10 01:32, DustDFG escribió:
>> > On Tue, May 10, 2022 at 1:12 AM Matias Fonzo <selk@dragora.org> wrote:
>> >
>> >> El 2022-05-06 03:58, DustDFG escribió:
>> >> > Hello Matias!
>> >> >
>> >> > I am sorry for the delay
>> >>
>> >> No problem!
>> >>
>> >> > On Thu, Apr 28, 2022 at 7:00 PM Matias Fonzo <selk@dragora.org>
>> wrote:
>> >> >
>> >> > The size of the ISO matters, since we have to create the images for
>> >> >> several CDs, in 700mb maximum. To achieve this you have to adjust or
>> >> >> change the output of the packages for the files containing the build
>> >> >> orders. For example, the packages generated from 00-core.order would
>> >> >> be
>> >> >> installed to /var/cache/qi/packages/cd1/ with the rest continuing to
>> >> >> wrap their output for the next CD number. So from stage 2 you can
>> >> >> create
>> >> >> the images for the CDs. It also gives the possibility of doing what
>> >> >> you
>> >> >> suggested before, once the packages are generated, they will be
>> >> >> available in the packages/ directory, when chrooting in, Qi can be
>> >> >> used
>> >> >> to install directly, for example. the core from
>> >> >> var/cache/qi/packages/cd1.
>> >> >>
>> >> >
>> >> > As I know, now qi has an `--outdir` command line option. It can't give
>> >> > you
>> >> > several cd's by stripping size but you can easily move all packages
>> >> > from
>> >> > the 00-core.order to folder var/cache/qi/packages/cd1
>> >> >
>> >>
>> >> Yes, and measure its size to see if it fits in 700 MB. Other series
>> >> can
>> >> make up the "cd2" and so on...
>> >>
>> >
>> > It seems to me that qi mustn't do it. It seems to me that it must do
>> > something wrapper....
>>
>> Yes, from the 'build-for-release' script.
>>
>
> I understood that cdN must depend only on packages from it or other
> cd's
> with number lesser than N.
> Does the order files follow this idea?
Right now the 'build-for-release' script proceed with all the order
files. What I have in mind at the moment, is to process for example
"00-core.order" which would compose a CD (CD1), and see in the following
orders, e.g "01-sound", "02-dict" and maybe "03-xorg" could compose
CD2...
OK. Now I want to know the difference between bootstrap stages and build-for-release.
I can't understand. Why aren't they a one object?
>>>
>> >> >> Apart from this, my proposal is to create a rootfs, which you unpack
>> >> >> directly, which is more direct and faster than having to install
>> >> >> packages one by one via Qi.
>> >> >>
>> >> >
>> >> > It is something like `darkcrusade` compiler collection. I also think
>> >> > that
>> >> > the rootfs can be a template for different image types (iso, qcow ...)
>> >> > so I
>> >> > thought that the rootfs and the core image is one entity.
>> >> >
>> >> > It seems to me that it will be good to have an xx-bootstrap.order that
>> >> > contains minimal system that you can run...
>> >>
>> >> For a minimal system it is needed to identify, mark or sub-categorize
>> >> the most essential packages required to run the system.
>> >>
>> >
>> > What do you propose?
>>
>> Well... the category of a package can be renamed to "essential", or
>> the
>> essential packages can be declared in a new order file.
>>
>> Alternatively for a minimal system you can make a new stage containing
>> the C library, the kernel, perl, graft and qi, the init system, and
>> maybe other packages like busybox plus utilities to make network or
>> internet available.
>>
>
> I almost like this idea :)
>
> I think that it is already almost done because the stage 1 produces a
> temporary
> system that looks like the core system or the rootfs. I think that
> creation
> of a new stage
> is a bit unnecessary action. I think that we really need to make a new
> `essential`
> order file (maybe with a new category with the same name) that contains
> only
> packages from the stage 1. It will permit not to change scheme of
> system
> building
> but it will give possibility to get rootfs or the core system.
> What do you think about it?
Stage 1 provides software to build more software, for a minimal system
we don't need this, but a small system that can install the rest (or the
desired available) binary packages, local or remote would be great.
About a new order file for essential packages, sounds good. I think it
would also be a good idea to rename the category of those (super)
essential packages. To identify them, to be able to search them more
easily, where maybe also the installer can offer such packages,
installation.
00-essential.order, 01-core.order, 02-sound.order ...
Move these packages to category essential: "The C library, the kernel,
perl, graft and qi, the init system, and maybe other packages like
busybox plus utilities to make network or internet available."
Do you think about something like this?
> In one of your previous messages you write that rootfs can be an
> archive.
> You also pointed
> out that archive is much faster than installing qi packages one by one.
> But
> it can be produced
> by installing qi packages one by one into the system. After installing
> the
> packages you can
> archive filesystem and get the rootfs...