dragora-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Matías Fonzo
Subject: Re: [Dragora-users] Proposal: flexible script to create different images
Date: Mon, 06 Jun 2022 08:30:19 -0300
User-agent: Roundcube Webmail/1.4.12

El 2022-06-06 08:04, DustDFG escribió:
On Sat, Jun 4, 2022 at 10:38 PM Matías Fonzo <selk@dragora.org> wrote:

El 2022-06-03 23:52, DustDFG escribió:
> On Fri, Jun 3, 2022 at 4:46 PM Matías Fonzo <selk@dragora.org> wrote:
>>
>> El 2022-06-03 04:47, DustDFG escribió:
>> > On Thu, Jun 2, 2022 at 6:49 PM Matías Fonzo <selk@dragora.org> wrote:
>> >>
>> >> El 2022-06-02 09:29, DustDFG escribió:
>> >> > Hello Matias!
>> >> >
>> >> > I apologize for coming back to this
>> >> >
>> >> > On Thu, Apr 28, 2022 at 7:00 PM Matias Fonzo <selk@dragora.org> wrote:
>> >> >>
>> >> >> El 2022-04-27 04:12, DustDFG escribió:
>> >> >> > Hi,
>> >> >> >
>> >> >> >> No, I was talking about to modify the output of packages by default
>> >> >> >> (from Qi), but first I want to check if we can just include the
>> >> >> >> packages
>> >> >> >> in a ISO handling the category name in the packages, for e.g: all 
the
>> >> >> >> @core.tlz packages for the ISO (CD 1).
>> >> >> >
>> >> >> > I think that if we don't worry about size of this iso image, it 
doesn't
>> >> >> > look like
>> >> >> > a problem because we can use 'find' utility. I still can't understand
>> >> >> > what
>> >> >> > you
>> >> >> > mean. What does modification of packages by default means?
>> >> >>
>> >> >> 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.
>> >> >>
>> >> >> 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.
>> >> >>
>> >> >
>> >> > What do you think the rootfs must contain?
>> >>
>> >> The rootfs can contain whatever the final system produces, usually
>> >> everything (packed in a tar.gz).
>> >>
>> >>
>> >
>> > It will be a big file. Why not tarlz?
>>
>> Because tar/gzip is more widely supported, and some laptops
>> (Chromebooks, if I'm not mistaken) only support this format (to be
>> loaded in a SD card), I don't know if other formats are supported.
>>
>> > I also want to ask you about temporary system. Can we pack it like a
>> > cross-compiler?
>>
>> I don't recommend it, since they contain the hard-coded paths to
>> fulfill
>> its purpose, a prior step ensuring that the final system build will
>> not
>> be contaminated by host system stuff.
>>
>>
>
> Is it only tools directory?

Yes, exactly.  This does not represent a running system (with a kernel
image, etc.) but it is about temporary tools to build the final system.


I tried to understand what depends on hard coded paths but I couldn't
do it. In every place we know where is tools directory. I can't
understand why we need link to tools directory and what depends on it.
Could you explain it, please?

It is enough to do a `grep tools stages/1/*` to know what depends on /tools. Both the installation of tools and the dynamic linker are going to look through this path, in order to isolate the host system, mainly the isolation of the C library with respect to the system in which you run with the system you want to build. This is somewhat documented[1] and done by projects such as Linux From Scratch[2].

From [1]:

"
The overall goal of Chapter 5 and Chapter 6 is to produce a temporary area that contains a known-good set of tools that can be isolated from the host system. By using chroot, the commands in the remaining chapters will be contained within that environment, ensuring a clean, trouble-free build of the target LFS system. The build process has been designed to minimize the risks for new readers and to provide the most educational value at the same time.
"

[1] https://linuxfromscratch.org/lfs/view/development/partintro/toolchaintechnotes.html
[2] https://linuxfromscratch.org/lfs/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]