Liblinuxlive-based LFS?
I'm interested in putting together a version of the LFS book that uses the liblinuxlive scripts (http://www.linux-live.org) for making bootable ISO images. I'm curious first what people's opinions are of such a topic, and second what the best way of going about this is. My initial instinct is that it should be a different book akin to CLFS or HLFS, but at it looks to me like these are indeed completely separate projects; in an ideal universe, what I'm after would basically be the LFS book with a few substitutions (kernel build, boot scripts, and install steps). Is there a way to do that sort of thing? Any thoughts are welcome. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Book XML design specs, extending LFS
So I've been looking at the book XML in more depth, since I'm definitely interested in getting involved in the LFS projects. I've been looking mostly at the CLFS book, since much of my hardware is x64-based. In looking at it, I've found myself wondering if there's an "overall design" sort of document somewhere that talks about best practices, and why things are put together the way they are. Particularly, as I mentioned, I'm interested in what would be considered to be the best way to "extend" an existing book, in a way that's most compatible with the existing books. For the case I'm after at the moment (the bootable ISO), the vast majority of the steps would be identical; the only differences would be some extra steps in the kernel build, the boot scripts, and an extra step after installing packages. I can think of three ways to do this: 1. Add a new attribute (perhaps "profile.condition=iso"?) to the Makefile, and add the extra steps to the existing XML. This has the greatest impact on the existing book, but also is the easiest to keep the new steps in sync. This might not be easily maintained as a patch. 2. Add a new directory within the book for the new build type, mirror the directory and file structure, and use XInclude/XPointer to include all the identical pieces. This is zero impact to the existing book, but is much harder to keep synchronized. This could probably be maintained as "unpack this tarball into the BOOK directory". 3. Make it a whole new book, starting its life as a copy of an existing one. As the person who's looking to do this, of course, I'd personally prefer #1 - but I also recognize that means that I'm playing in somebody else's sandbox. The advantage here is that I'm more than happy to help with the mainline development, since it would all fully apply to my build as well. For instance, I have succeeded in building CLFS with newer versions of several of the packages - is there somewhere I should forward those changes to? My eventual goal (via jhalfs) is to be able to get pushbutton creation of "appliance" CDs. I've been using a heavily-modified Slax image, but ultimately I need more control over the final product than I can easily get with Slax. So I'd be interested in helping with jhalfs development as well - for instance, distcc support in jhalfs would be a wonderful thing (I've been using it with good success in CLFS builds, albeit with a lot of manual help). So - what are your thoughts on the best way for me to proceed with this? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Book XML design specs, extending LFS
Gilles Espinasse <[EMAIL PROTECTED]> wrote: > I doubt distcc is a big gain on x86_64. > CPU is so fast comparing to the network and with lot of internal cache that > minimize the gain you could achieve using other machines. > That's supported on IPCop and the gain reported was only 5% adding another > machine with same power. So that's not worst the work and probably almost > nobody really use it. > Should be more usefull if you have a cloud of slow alpha, pcc or sparc > machines. > To be more efficient with less network traffic needed, you would need a > system able to distribute an entire package compilation (when packages are > fully independant) at each machine. I am not so sure distcc will help on > that scheme. > I realize that I am probably not the typical case, but I saw a substantial gain - I had four machines (10 cores total) hooked up via GigE, so network latency was not so much an issue for me. But you have a good point in that being able to distribute the packages themselves would be even better; I'll contemplate good ways to do that; at the very least, in order to support the "parallel package build" idea, one would need a tag for a step specifying which steps it is dependent on. > In contrary, ccache is approximately an overall 25% gain after the first > build. > That really help compiling the kernel for example (gain should be 50% > there). > So in light of that, I'll rephrase that to "support for compiler wrappers" in general. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Aiming for 7.0
Jeremy Huntwork wrote: > * DESTDIR style PM support? (To me, this is the easiest way of offering > a default pseudo-style PM support. We don't actually tell the users how > to package up the binaries, track dependencies or track what is > installed, but we do show whatever DESTDIR-compatible commands exist for > the package so that LFS can be that much more compatible with a wide > range of PM offerings). > This actually dovetails very nicely with the work I've been doing for the Linux-Live-flavoured LFS. In order to turn the built packages into SquashFS modules, I found that I was basically doing everything necessary to implement this exact basis of package management. So what I did in my work was implement a new (which in my opinion should be able to be switched on and off via profiling), which does the fakeroot install. The command to actually turn that into a SquashFS module is wrapped in a profiling switch specific to Linux-Live. So in an ideal universe, it could look something like this: ... Binary Package for Foo Perform the fakeroot install: make DESTDIR=$PKGTEMP install Build the Squashfs filesystem: mksquashfs $PKGTEMP ../foo-&foo-version;.$SQEXT $SQOPTS Build the package tarball: tar -C $PKGTEMP -cjf ../foo-&foo-version;-bin.tar.bz2 * Does this look reasonable? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Aiming for 7.0
Bruce Dubbs wrote: > Bryan Kadzban wrote: > >> > Ticket 2033 -- initramfs. This way people with crappy software "RAID1 >> > cards" (e.g. Promise, Highpoint, etc.) that require drivers in Windows, >> > can still boot from those cards. Also, support for MD RAID (*real* >> > software RAID ;-) ), LVM, and encrypted rootfs would be nice. >> > >> > (The mkinitramfs repo linked to from that ticket will already work for >> > everything above, except encrypted rootfs.) >> Again, this is very, very probably something I will need to do for Linux-Live support; I'm not 100% positive yet, but I do know that for the sort of application I am after, I personally will need an initramfs; I need something that will run on any PC system, which means I can't just compile the specific drivers I need for boot into the kernel. (And indeed, that includes fakeraid.) > > Even it it's poor hardware support, does the frequency of occurrence rise to > the > level of needing to be in the LFS book? As several comments in the ticket > suggest, initramfs would be more appropriate for BLFS, but I'm thinking that > even that is too much and an updated hint or wiki entry would be more > appropriate. > So, here's something to ponder... is it a requirement that the LFS book be 100% linear? That is to say, that the build process is always identical? The reason I ask is this: if you're starting from the XML, using profiling it's pretty simple to generate different books out of the same source. Perhaps a hybrid approach could be taken to generating the HTML, with something like a little JavaScript page at the beginning to set options like initramfs or package management, and the necessary links and sections could be displayed accordingly? Failing that, perhaps a message to the effect of "If you do not require initramfs support, you may skip this section" with a helpful link to do so? Just some thoughts, I'm not sure of the best way for such a thing myself. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: lfs-dev Digest, Vol 1235, Issue 1
Gordon Schumacher wrote:
> So what I did in my work was implement a new
> (which in my opinion should be able to be switched on and off via
> profiling), which does the fakeroot install. The command to actually
> turn that into a SquashFS module is wrapped in a profiling switch
> specific to Linux-Live.
I think I have an even better idea: rather than putting *any* package
management commands in, what about something like this:
If you would like to generate binary packages, you will need to
define a function that will be used to generate those packages. Run a
command similar to the following:
cat >> ~/.bash_profile << "EOF"
make_package() {
tar cf $1.tar.bz2 $PKGTEMP
}
EOF
Then, in the XML for each package:
Binary Package for Foo
If desired, perform the fakeroot install and build the
package
if [ "$(type -t make_package)" == "function" ]; then
make DESTDIR=$PKGTEMP install
make_package foo-&foo-version;
fi
I think that this would satisfy all the desires stated: not supporting a
specific package manager, supporting package management if people want
it, and still allowing for automation!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Proper use of digests [was: Re: lfs-dev Digest, Vol 1235, Issue 1]
TheOldFellow wrote: > If you MUST reply to a digest, do try and get the Subject right. My error, I missed it on that message. I *do* try - since I did get it right on my other messages. I forgot this time. But what is the further intent here - the digest shouldn't exist? That one should use it only for reading? If one shouldn't reply to digests, it might be possible to write a mail rule to automatically clear the "new message" flag on any incoming e-mail that is from a mailing list; I personally dislike getting "new message" notifications every minute or two. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Package management (was: Aiming for 7.0)
Gordon Schumacher wrote:
> I think I have an even better idea: rather than putting *any* package
> management commands in, what about something like this:
>
> If you would like to generate binary packages, you will need to
> define a function that will be used to generate those packages. Run a
> command similar to the following:
>
> cat >> ~/.bash_profile << "EOF"
> make_package() {
> tar cf $1.tar.bz2 $PKGTEMP
> }
> EOF
>
>
> Then, in the XML for each package:
>
>
>Binary Package for Foo
>
> If desired, perform the fakeroot install and build the
> package
>
> if [ "$(type -t make_package)" == "function" ]; then
> make DESTDIR=$PKGTEMP install
> make_package foo-&foo-version;
> fi
>
>
>
>
> I think that this would satisfy all the desires stated: not supporting a
> specific package manager, supporting package management if people want
> it, and still allowing for automation!
>
So... does this look reasonable to folks? Anyone have any objections to
me working on implementing this against the current trunk and submitting
it as a patch?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Package management
Matthew Burgess wrote: > As I'm sure you're already aware, Gordon, we have historically tried to stick > to > an entirely linear, no-optional-extras format to the book. As such, I would > prefer it if we just went whole-heartedly into DESTDIR support, no ifs, buts > or > maybes :-). > In fact, that's the route I've been working on - I've cleaned up my last posting a bit further, and I'm working on a build now - ironically, tripped up by a jhalfs-trunk bug - remove_existing_dirs in makefile-functions has a reference to $(SRCDIR) that should be $(SRCSDIR). (I'm in the process of subscribing to alfs-discuss as well.) > So, I'd be more than happy to review any patch(es) you make against trunk. I > suspect this may need a change to jhalfs, which I use to automate my builds, > so that it will optionally define your make_package() function, but I don't > think that will be too hard for me, you or someone else to fix up. > Yeah, for the moment I've hacked around it - I wasn't quite sure how to go about that. But I have some other thoughts on jhalfs as well, but I can go into those there :) > Thanks for working on this! It's alway nice to see new contributors! > Hey, this is a huge help to me as well - I was well on my way to defining an XML spec for downloading and installing packages from Slackware tarballs or from source when a friend of mine said, "Hey, this looks just like LFS..." This is why I love open-source software! -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Mangement
Matthew Burgess wrote: > On Tue, 09 Dec 2008 03:11:09 -0600, DJ Lucas <[EMAIL PROTECTED]> > wrote: >> > It's not enough just to tar up the DESTDIR. You need to >> > consider installing the package (which IMO should be done by a script >> > created in the DESTDIR after removing any updated/dynamicly generated >> > files). That way you can create a tarball that is PM neutral and ready >> > for any real packaging scripts that you want to throw at it. I guess my >> > question is "What was the goal when this was decided?" 'make >> > DESTDIR=foo install', inspect the DESTDIR, and then 'make install'? >> > While I guess that there is nothing specifically wrong with that >> > approach, the DESTDIR is pretty much useless IMO, might as well stick to >> > installation logging. Well... I wouldn't go so far as "useless", but you're right, it leaves out some important stuff. What about using the format that checkinstall uses for this sort of information? (Not to actually create the package - just to define the "hooks" for package description, scripts, and such.) > I was under the impression that Gordon's patches would just be a starters for > 10. I kind of assumed that we'd have an 'install_package()' function as an > analogue to 'make_package()'. In its simplest form, this would simply > untar the package tarball created by make_package(), but there's obviously > plenty of scope for it to do much more. Quite how much of that potential we > want to make use of in LFS, and how much we should leave as an exercise for > the reader will probably take a bit more discussion. Indeed, I'm not even attempting to address that yet - for the immediate moment, just getting each package's files isolated into its own tarball is such a big first step that I'm willing to deal with any changes that need to be made to install those packages. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
