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: DustDFG
Subject: Re: [Dragora-users] Proposal: flexible script to create different images
Date: Mon, 6 Jun 2022 15:04:05 +0100

On Mon, Jun 6, 2022 at 12:31 PM Matías Fonzo <selk@dragora.org> wrote:
>
> 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/
>
>

It seems to me that gcc has linker option -rpath...



reply via email to

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