Re: Final prep for 6.3
Nathan Coulson wrote: On 8/10/07, Dan Nicholson [EMAIL PROTECTED] wrote: On 8/10/07, Nathan Coulson [EMAIL PROTECTED] wrote: Do hope to come back to it someday though, Who is in charge of the bootscripts these days? I think DJ officially, but I've been doing most of the maintenance for a while. I'd love to see you involved again Nathan, there's quite a few things I'd like to address about the bootscripts. Most people don't seem that interested in peering into the ugly corners of init.d/functions, though :) I think for LFS-7.0, we should consider the LSB style scripts that DJ has in contrib/lsb-v3. There's a couple patches floating around on lfs-dev, too, even if we don't go full bore LSB style. Not much has changed, but I think all the *proc functions could have a thorough cleaning. Some things in there are either suboptimal or just wrong (mostly with handling of pid files). -- Dan -- thanks dan, coming back from holidays in a coupple of weeks, maybe (if DJ doesn't mind, and work doesn't keep me away again), I'll see if I can get back in action. I haven't touched the bootscripts since I thought you were back last time. Didn't know I was 'responsible' for them still. I have had barely more time than you. Hell LSB-V3 sat on my dev box for months before I finally got them cleaned up. I still need to get the last change to checkfs in there before the 6.3 tarball is rolled too. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Jeremy Huntwork wrote: Hello, Hello snip / Essentially, the LiveCD is a distribution. But it is a distribution without something that nearly all others have: package management. Up to now, there hasn't really been a need. But, if the CD incorporated PM at its very heart, developers could focus more on tightening individual components instead of always building the entire CD in one shot. snip / If you like the sound of this new approach, please share your thoughts on what might help make it work. Details need to be discussed, such as the exact development model, package management tools, updated development scripts, tracking dependencies and standards for development. I'll wait until there is some discussion before I speak any further on some of the details that are already forming in my head. Disclaimer: Please take my comments as those of a lurker - rather than anyone with any actual authority on this subject. Jeremy - that sounds like a cracking idea but I strongly believe that it should go much further than the LiveCD... The idea of PM for {L,B}FS is one of the frequent questions to pop-up on these lists. There has also been discussion recently about how to invigorate the community and the project. I have been doing LFS for many years (LFS ID#216) but in the recent past now use Ubuntu for daily use. The reason why I don't do {L,B}FS much now? Because it is such a PITA to keep up-to-date. [Me dons an asbestos suit]. From a personal perspective, if there was an easier and more integrated way to maintain a {L,B}FS system I'd still be using it; with Ubuntu, that just works. I believe that if {L,B}FS (and the LiveCD) are developed to provide an integrated package management tool (but let's do it in the LFS style) or more like an automated build/upgrade tool, it would be a real boost to the project as a whole and garner a lot more support from the community at large. Maybe this should/could be the goal for LFS 8 or perhaps 10 ;-)? Lastly, I'm posting this to {,b}lfs-dev because I'd like to make sure those current groups of readers have the opportunity to comment. If possible, though, please send discussion to the livecd list. Sorry - I get in via gmane and the livecd list isn't on there - never has either to my knowledge... Alan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Jeremy Huntwork wrote: package management +1. This would also simplify production of the minimal CD (compile all packages as a side effect of building the full CD, then install only needed ones), and reduce the size of the main CD (because we don't want to ship, e.g., headers for gtk+ - so let's put them into a separate package that is discarded in the ISO creation process). The first step would be to convert everything to DESTDIR-style installation, and then adapt some existing (Slackware?) scripts to package the result. IMHO, RPM would be overkill here. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On 15 Aug 2007 Wed 11:25 am, Alan Lord wrote: Disclaimer: Please take my comments as those of a lurker - rather than anyone with any actual authority on this subject. I will also take the above disclaimer and apply it to myself Jeremy - that sounds like a cracking idea but I strongly believe that it should go much further than the LiveCD... Strongly agree I have been doing LFS for many years (LFS ID#216) but in the recent past now use Ubuntu for daily use. The reason why I don't do {L,B}FS much now? Because it is such a PITA to keep up-to-date. [Me dons an asbestos suit]. Me too although not as long as Alan :). The old timers of you may recall that I did do such a complete package management and build system for B/LFS using the RPM package management system. I recall that I did post my scripts and package configuration files for all to use. I too had to (sorrowfully) move to kubuntu as I didn't have the time to single handedly follow LFS, incorporate the package management and keep my system up to date. Perhaps my system could be of use? -- Shane Shields Registered LFS Compiler: 7582 To drink the WINE of success you must first seek the sayings of source Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. NOT : Bu mesaj ve ekleri mesajda gönderildigi belirtilen kisi ya da kisilere özel olup gizli bilgiler içeriyor olabilir. Mesajin muhatabi degilseniz lütfen mesaji herhangi bir sekilde kullanmayiniz ve mesaji gönderen kisiyi bilgilendirerek ekleri ile birlikte derhal imha ediniz. Mesaj göndericiye ait olup, Erkunt Tarim Makinalari Sanayii A.S.'nin herhangi bir sorumlulugu bulunmamaktadir.Mesajin size gönderilmesinden, bilgilerin dogrulugundan, bilgisayar sistemine verebilecegi zararlardan ve burada sayilanlar ve sayilmayanlar da dahil dogabilecek tüm zararlardan Erkunt Tarim Makinalari Sanayii. A.S sorumlu tutulamaz. QS Disclaimer Demo. Copyright (C) Pa-software. Visit www.pa-software.com for more information. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Alexander E. Patrakov wrote: The first step would be to convert everything to DESTDIR-style installation, and then adapt some existing (Slackware?) scripts to package the result. IMHO, RPM would be overkill here. Pacman rules!!! :-) Oops, sorry, back on topic. I guess Slackware scripts could be adapted judging by the content at Jaguar Linux: http://www.jaguarlinux.com/ Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Greg Schafer wrote: Pacman rules!!! :-) Oops, sorry, back on topic. I guess Slackware scripts could be adapted judging by the content at Jaguar Linux: http://www.jaguarlinux.com/ Thanks for the link. Indeed, it looks that a lot of work has been already done for us. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Alexander E. Patrakov wrote: Greg Schafer wrote: Pacman rules!!! :-) Oops, sorry, back on topic. I guess Slackware scripts could be adapted judging by the content at Jaguar Linux: http://www.jaguarlinux.com/ Thanks for the link. Indeed, it looks that a lot of work has been already done for us. If anyone is interested and/or familiar with Solaris' package management system, I have written a set of scripts that implement that package manager on linux (*NIX really). You are more than welcome to them if you want them. There are 4 scripts to it and they are so generic that they will even work on older QNX systems. One of the nice things about the Solaris package manager is that *every* file installed is registered in a database (just an CSV file so no DB software like SQL needed) so it's easy to find out what has been installed. Package removal references the database to remove files. Furthermore, more than one package or more than one instance of the same package can claim ownership of a file such that removal of a file will not occur until the last package claiming ownership of a file is removed. During removal, only registered files are removed so any user created files remain. Registered directories are only removed if they are empty so if the user adds files to a registered directory after installing a package, package removal will not delete them because they are not registered and the registered directory will then not be removed. This prevents loss of user generated configuration files and the like. The package manager can solicit information from the user if needed. This can be for things like agreeing to license agreements or allowing the user to select his desired installation directories, etc. The nice thing is it's really easy to use in terms of package installation or removal. Package installation is: ./pkgadd -d . Package removal is pkgrm pkgname Well, this got much more long winded than I intended. If interested or you want more info, let me know. Or, if you happen to have access to the Solaris package manager documentation, take a look at it. Everything in it is implemented in my script based version. Mike -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Resolution (was Re: jh-branch)
Alexander E. Patrakov wrote: Yes, I think this is good enough for now for the DIY reference build, if it is clearly stated that the patch is a workaround. Not sure about LFS - the x86 build is not affected, the x86_64 branch apparently (Jeremy: am I right?) should not be used (because it is merged into jh), and the jh branch solved the problem by upgrading binutils. Yes, you are correct. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Shane Shields wrote: On 15 Aug 2007 Wed 11:25 am, Alan Lord wrote: Jeremy - that sounds like a cracking idea but I strongly believe that it should go much further than the LiveCD... Strongly agree I would love to see some sort of proper support for PM go into LFS, but that all depends on the community... The old timers of you may recall that I did do such a complete package management and build system for B/LFS using the RPM package management system. I recall that I did post my scripts and package configuration files for all to use. I too had to (sorrowfully) move to kubuntu as I didn't have the time to single handedly follow LFS, incorporate the package management and keep my system up to date. Perhaps my system could be of use? I hate to say it, but I don't recall your system. Do you have a link of some sort? I've had some little bit of experience building RPM co. and it gets to be a bit of a beast. I think as of now, I'm leaning towards the Slackware-style suggestion. I need to go check out the link that Greg posted. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Jeremy Huntwork wrote these words on 08/15/07 07:20 CST: I would love to see some sort of proper support for PM go into LFS, but that all depends on the community... I'll go on record as -1. I feel we should mention it, provide links to the various alternatives, and drive on. We are not a distribution. We are a book that shows how to compile Linux from scratch. Let's don't forget that. Package management is beyond the scope of showing how to compile packages (and which packages to compile). -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 07:37:01 up 13 days, 7:28, 1 user, load average: 0.10, 0.12, 0.04 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Greg Schafer wrote: Alexander E. Patrakov wrote: The first step would be to convert everything to DESTDIR-style installation, and then adapt some existing (Slackware?) scripts to package the result. IMHO, RPM would be overkill here. Pacman rules!!! :-) Oops, sorry, back on topic. I guess Slackware scripts could be adapted judging by the content at Jaguar Linux: I agree with Greg, Pacman is superior to Slackwares Pkgtools and does not depend on a quirk only available in tar = 1.13.. I have created numerous interchangeable PM modules (DPKG, Pacman, Pkgtools and Pkgutils) for my personal education/use, for Greg's DIY code and use the progenitor of Pacman, Per Liden's Pkgtools. I would not recommend the Slackware PM due to the 'tar' limitation and its lack of sophistication and DPKG is for masochists ( 3. A willingness or tendency to subject oneself to unpleasant or trying experiences.) http://www.jaguarlinux.com/ Regards Greg -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On Wed, Aug 15, 2007 at 07:37:12AM -0500, Randy McMurchy wrote: I'll go on record as -1. I'm not going to push to get this into LFS. If the vast majority of those with a voice here are for PM in LFS, great. If not, great. :) I feel we should mention it, provide links to the various alternatives, and drive on. We are not a distribution. We are a book that shows how to compile Linux from scratch. Let's don't forget that. Understandable. Of course, it could be argued that part of what makes a Linux system is package management. It is after all part of the LSB. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Randy McMurchy wrote: Agreed, but then that vast majority must also come to agreement so that a vast majority of those decide on *which one* to use. We've already had about 5 people comment with 5 different PMs. It'll never happen (hopefully). :-) The idea is not to put a concrete package manager into the book, but to make instructions in the book PM-friendly. I.e., 1) add DESTDIR support to every package, instead of requiring each packager to reinvent the same wheel; this also means the install-nokeys target on the openssh page 2) verify that each package builds the same binaries (in the ICA-like sense) when built as root vs non-root. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
George Boudreau wrote: I agree with Greg, Pacman is superior to Slackwares Pkgtools and does not depend on a quirk only available in tar = 1.13.. Could you please explain in more detail? According to ftp://ftp.slackware.com/pub/slackware/slackware-current/source/a/tar/tar.SlackBuild, the quirk is: # This old version is the only one that won't clobber synlinks, e.g.: # someone moves /opt to /usr/opt and makes a symlink. With newer # versions of tar, installing any new package will remove the /opt # symlink and plop down a new directory there. # Well, there's a lot of other bugs (the remote stuff particularly I'm # told is flaky) in tar-1.13, so it'll only be here now for use by the # Slackware package utils. And, we'll even let people remove it and # the pkgutils will still try to work (but eventually they'll pay the # price :) But IMHO, making such symlinks means shooting oneself in the foot, because there are disk space management solutions (e.g. ext3 on LVM2) that are superior to plain old partitions (i.e., allow online resizing). So the above reason is not valid enough for me. Or do you mean another quirk? -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On Wed, Aug 15, 2007 at 06:59:55PM +0600, Alexander E. Patrakov wrote: # This old version is the only one that won't clobber synlinks, e.g.: # someone moves /opt to /usr/opt and makes a symlink. With newer # versions of tar, installing any new package will remove the /opt # symlink and plop down a new directory there. # Well, there's a lot of other bugs (the remote stuff particularly I'm # told is flaky) in tar-1.13, so it'll only be here now for use by the # Slackware package utils. And, we'll even let people remove it and # the pkgutils will still try to work (but eventually they'll pay the # price :) Also, FWIW, I've done testing and this bug disappears with recent tar. I think the last one I tested was 1.16. I even spoke with Patrick Volkerding about it and he acknowledged that the bug hasn't been present in the latest versions. But he said he's inclined to leave the requirement in place since it is known to work and to avoid potential future problems of a similar nature. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Jeremy Huntwork wrote these words on 08/15/07 08:07 CST: On Wed, Aug 15, 2007 at 07:37:12AM -0500, Randy McMurchy wrote: I'll go on record as -1. I'm not going to push to get this into LFS. If the vast majority of those with a voice here are for PM in LFS, great. If not, great. :) Agreed, but then that vast majority must also come to agreement so that a vast majority of those decide on *which one* to use. We've already had about 5 people comment with 5 different PMs. It'll never happen (hopefully). :-) -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 08:13:00 up 13 days, 8:04, 1 user, load average: 0.43, 0.19, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Alexander E. Patrakov wrote these words on 08/15/07 08:24 CST: 1) add DESTDIR support to every package, instead of requiring each packager to reinvent the same wheel; this also means the install-nokeys target on the openssh page Good point. Though I don't see it as being something that LFS needs to do. We as Editors are deeming our build method as safe. Why would we want to create extra work for what we already know? (redundant question, as you semi-answered it by saying that it makes the instructions PM-aware) 2) verify that each package builds the same binaries (in the ICA-like sense) when built as root vs non-root. I do not see value in this at all. In LFS we are chrooted, so root is a given. In BLFS, one should never build as root as a matter of general principle. The same as one should never open a shell (or run a GUI) as root. -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 08:27:00 up 13 days, 8:18, 1 user, load average: 0.00, 0.05, 0.07 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
[EMAIL PROTECTED] wrote: You could also consider using config.site like DIY Linux does. I tried it and I have had no problems with it. Already used in the LiveCD for the purposes of compiling with sensible architecture and optimization flags, as well as removing /usr/{man,info} symlinks and almost all static libraries. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On Wed, Aug 15, 2007 at 03:29:47PM +0100, Alan Lord wrote: Jeremy Huntwork wrote: This is pretty much what I said in the LiveCD users thread you started on the 18th of last month on the general list... In fact here's my comments from that. Yes, I recall that. And I remember agreeing with it. I just didn't quite see how to bring that to fruition at the time. I would encourage anyone interested in pursuing this to join the livecd list. Alan, I'll see if I can't get gmane to handle that list as well. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On Wed, 15 Aug 2007 00:02:07 -0400 Jeremy Huntwork [EMAIL PROTECTED] wrote: Hello, As I've been giving some thought to what might make the LiveCD project more manageable, more open to community development and better all around, it occurred to me that our build method could be adjusted. Right now the build is automated by a long series of Makefiles that was, in some respects, the inspiration for jhalfs. You set some variables, run make, wait 6 hours or so, and voila! (hopefully) a LiveCD. It gets very difficult (or, at least, annoying) to develop because of the long times involved in building the entire thing. First up, I should say that until yesterday I didn't use the LiveCD, I had one (from long long ago) but it was curio. I build the next LFS on the old LFS... Yesterday my friend gives me his old laptop - I'm looking for a zero-cost zero-fan replacement for my router, and I need LFS on it quickly. I downloaded the 6.2-5 image and was up in am hour - it even correctly detected the pcmcia lan card, and the xorg.conf was spot on. Note also that neither fedora-6 nor ubuntu-7 would have anything to do with this box. So I'm impressed. (and I'd like to see instructions for loading the precompiled image onto the HD and making it bootable - I can do it, but then...) So an idea is brewing... Essentially, the LiveCD is a distribution. But it is a distribution without something that nearly all others have: package management. Up to now, there hasn't really been a need. But, if the CD incorporated PM at its very heart, developers could focus more on tightening individual components instead of always building the entire CD in one shot. If the LiveCD build process has a package manager, then 'ipso facto', so does {b}lfs. For example, let's say a flaw was found in one of the pieces of software included on the CD. With the PM incorporated into the build, all we would need to do is grab the latest packages, run a small script to install them into a working directory with the proper configuration, update the build commands for the package in question, rebuild it, re-package it, and re-release an ISO. Working in this method should shorten build times, help solidify the build, and open up a host of other possibilities. A package manager doesn't absolve you from regression testing. It just makes it easier to get the thing built. The Live CD, almost more than the Book, needs to work for a big proportion of those that try it. If you like the sound of this new approach, please share your thoughts on what might help make it work. Details need to be discussed, such as the exact development model, package management tools, updated development scripts, tracking dependencies and standards for development. I'll wait until there is some discussion before I speak any further on some of the details that are already forming in my head. If you use some little odd-ball PM, rather than, say RPM you will end up spending more development effort on the PM than on the LiveCD. Frankly, I think we should have a PM in LFS, indeed it MIGHT be good to build LFS as a distribution - so that you end up, not with a partition to boot, but with an LiveCD that has an Install application. Lastly, I'm posting this to {,b}lfs-dev because I'd like to make sure those current groups of readers have the opportunity to comment. If possible, though, please send discussion to the livecd list. Can't use LiveCD list, it's not on gmane. Let's try and get it on gmane, shall we? The arch-hives are the important thing. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: An idea for a new development model
Jeremy Huntwork wrote: On Wed, Aug 15, 2007 at 07:37:12AM -0500, Randy McMurchy wrote: I'll go on record as -1. I'm not going to push to get this into LFS. If the vast majority of those with a voice here are for PM in LFS, great. If not, great. :) I feel we should mention it, provide links to the various alternatives, and drive on. We are not a distribution. We are a book that shows how to compile Linux from scratch. Let's don't forget that. Understandable. Of course, it could be argued that part of what makes a Linux system is package management. It is after all part of the LSB. You mean RPM is part of the LSB. they REQUIRE that package management be fully RPM compatable. far beyond what a base standard should be in my opinion. the real reason that package managers are a bad thing, the bloated requirements of the meta packages in them. grab yourself a current debian install, and install KDE on it, minimal KDE without the kdeedu, games, development, pim package groups. you can't, Debian made the KDE meta package require 100% of all optional KDE software to install the base KDE. Debian did the same type of bloat with the Gnome meta package requirements, put way to much as absolutely required. I think Randy's phrasing is a far better way for the LSB to handle package managers. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
TheOldFellow wrote: If you use some little odd-ball PM, rather than, say RPM you will end up spending more development effort on the PM than on the LiveCD. I have tried privately (but together with Jeremy) to add RPM to /tools in LFS and convert all instructions to spec files. Result: I abandoned the effort because I could not get it right. RPM is indeed suitable for easy removal of packages, but my copy didn't pass the all official features are supported test. AFAIR, it failed to handle file conflicts correctly. So, after more than two weeks of fighting with it, I was with the rpm binary that is only marginally more capable than the pre-existing (and tried) Slackware scripts. And BTW, could you please test the 6.3 pre-releases of the CD? 6.2 is dead. As for installation instructions: the 6.3 CD can be run from an ISO file without burning it (support for this is built into initramfs, see the README file on the CD). Maybe this is good enough as a substitute for full installation onto a partition you only lose the ability for your changes to survive the reboot). -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
lists wrote: the real reason that package managers are a bad thing, the bloated requirements of the meta packages in them. grab yourself a current debian install, and install KDE on it, minimal KDE without the kdeedu, games, development, pim package groups. Easy: aptitude install kdebase kdenetwork Simply don't install the metapackage. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On Wed, Aug 15, 2007 at 03:41:52PM +0100, TheOldFellow wrote: was spot on. Note also that neither fedora-6 nor ubuntu-7 would have anything to do with this box. So I'm impressed. (and I'd like to see instructions for loading the precompiled image onto the HD and making it bootable - I can do it, but then...) Glad to hear it. There are a few ways to do this and there are even hints about it, IIRC. The latest fun allows for booting the iso as a file existing on an internal HD or USB disk. Thank Alexander for that one. Should the livecd archives show up on Gmane, you'll see a post about it there from about a month ago. A package manager doesn't absolve you from regression testing. It just makes it easier to get the thing built. The Live CD, almost more than the Book, needs to work for a big proportion of those that try it. Noted and agreed. If you use some little odd-ball PM, rather than, say RPM you will end up spending more development effort on the PM than on the LiveCD. Frankly, I think we should have a PM in LFS, indeed it MIGHT be good to build LFS as a distribution - so that you end up, not with a partition to boot, but with an LiveCD that has an Install application. There are neat things about RPM, and it is very widely used. But, GRRR!, getting it to play nicely can be painful. Can't use LiveCD list, it's not on gmane. Let's try and get it on gmane, shall we? The arch-hives are the important thing. Request made. Bee on the lookout. ;) -- JH -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: An idea for a new development model
On Wed, 15 Aug 2007 21:03:29 +0600 Alexander E. Patrakov [EMAIL PROTECTED] wrote: TheOldFellow wrote: If you use some little odd-ball PM, rather than, say RPM you will end up spending more development effort on the PM than on the LiveCD. I have tried privately (but together with Jeremy) to add RPM to /tools in LFS and convert all instructions to spec files. Result: I abandoned the effort because I could not get it right. RPM is indeed suitable for easy removal of packages, but my copy didn't pass the all official features are supported test. AFAIR, it failed to handle file conflicts correctly. So, after more than two weeks of fighting with it, I was with the rpm binary that is only marginally more capable than the pre-existing (and tried) Slackware scripts. I wasn't singling out RPM, especially - and your comments are germaine. I just think that it should be a mainstream PM, maybe RPM, Apt or Portage is too much, maybe Pacman is ideal. I don't have the knowledge. But I do know that any development model that doesn't choose it's core tools wisely ends up being a tools development project - remember my background (CTO). And BTW, could you please test the 6.3 pre-releases of the CD? 6.2 is dead. I will if I can find them. Is lfslivecd-x86-6.3-minimal-pre1.iso the one to use? The Readme isn't helpful (on ftp://ftp.osuosl.org/pub/lfs-livecd/READ_ME.txt a mirror from the website, at least) and I don't sub to LiveCd list. R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
TheOldFellow wrote: On Wed, 15 Aug 2007 21:03:29 +0600 Alexander E. Patrakov [EMAIL PROTECTED] wrote: And BTW, could you please test the 6.3 pre-releases of the CD? 6.2 is dead. I will if I can find them. http://ums.usu.ru/~patrakov/test/lfslivecd-x86-6.3-r2014.iso http://ums.usu.ru/~patrakov/test/lfslivecd-x86-6.3-r2014-nosrc.iso http://ums.usu.ru/~patrakov/test/lfslivecd-x86_64-6.3-r2014.iso http://ums.usu.ru/~patrakov/test/lfslivecd-x86_64-6.3-r2014-nosrc.iso The -nosrc variants differ only by the fact that they don't include sources. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
El Miércoles, 15 de Agosto de 2007 15:07, Jeremy Huntwork escribió: I'm not going to push to get this into LFS. If the vast majority of those with a voice here are for PM in LFS, great. If not, great. :) The question are: What changes would be needed to let *LFS books be PM-aware? Without forcing the use of an specific PM implementation, of course. Would that changes have some impact on that of us (read users) that don't want/need to use a PM? As least to me, if_something_work_as_needed==don't_upgrade, small-upgrade==reinstall_on_top, big_upgrade==build_a_ new_system. And lastly, like Rady said, the master goal of the LFS project is to provide educational books about how to build a Linux system. If PM support is added, who will writte the text explaining how to set-up and use a PM? Understandable. Of course, it could be argued that part of what makes a Linux system is package management. It is after all part of the LSB. LSB dictates that RPM must be available, but it don't tell that RPM must be used. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
M.Canales.es wrote: What changes would be needed to let *LFS books be PM-aware? Without forcing the use of an specific PM implementation, of course. DESTDIR (see how DIY handles it) and workarounds for parameters detected incorrectly by ./configure scripts when running as non-root. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
udev-114 progress with uClibc
Okay, so I finally found out how to make udev's 094 boot under a uClibc system. During the boot process prior to loading/starting udev, I have the following command happening: echo /sbin/udevtrigger /proc/sys/kernel/hotplug This works in udev094, for whatever reason it now causes udev to lock up and not produce proper devices. The end result is system does not boot and sits there. The solution was to change this to: echo '' /proc/sys/kernel/hotplug and suddenly the system boots. I worry that this will cause modules to not be auto-loaded when plugged in. However, this is a step forward into solving the problem. Its quite hard to tell if it will or won't work considering how much udev changes and how much udev has no documentation whatsoever by the udev team. -- Kevin Day -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
lists wrote: Jeremy Huntwork wrote: On Wed, Aug 15, 2007 at 07:37:12AM -0500, Randy McMurchy wrote: I'll go on record as -1. I'm not going to push to get this into LFS. If the vast majority of those with a voice here are for PM in LFS, great. If not, great. :) I feel we should mention it, provide links to the various alternatives, and drive on. We are not a distribution. We are a book that shows how to compile Linux from scratch. Let's don't forget that. Understandable. Of course, it could be argued that part of what makes a Linux system is package management. It is after all part of the LSB. The real reason that package managers are a bad thing, the bloated requirements of the meta packages in them. grab yourself a current debian install, and install KDE on it, minimal KDE without the kdeedu, games, development, pim package groups. you can't, Debian made the KDE meta package require 100% of all optional KDE software to install the base KDE. Debian did the same type of bloat with the Gnome meta package requirements, put way to much as absolutely required. This last observation is one of the main reasons i've been using Gentoo for 4 years - you don't even have to install all of 'kdebase' if you don't want to, much less the other meta-packages. However, their PM, Portage, must require an absolutely colossal amount of maintenance ( i'm just talking about the ebuild-tree, never mind the package-manager itself), so a similar system for {,B}LFS would almost certainly be impractical... During my only LFS-build thus far i used a combination of the pkgusr fakeroot hints, found the use of $DESTDIR to be particularly educational, as well as practical, so if the book were to encourage it's use more in future, i don't think that would detract from it's original goal of being a learning tool. I also whole-heartedly agree with Alan's earlier comment - The unfortunate consequence of LFS is that it also teaches the user how great a lean/mean Linux system can be (and most would want it to stay that way if it *was* a distribution). I would hazard a guess that most people who grok LFS would love to use it for their everyday distro. Perhaps the existing book-section on package-management could be embellished to the effect that These are some of the most popular options, of which we ourselves use this one in development of our LiveCD project - not so much a stipulation as an endorsement... Subsequent to listening to an ArchLinux advocate, looking at Greg's DIY project, i'm thinking of using 'pacman' on my own system, but i'm in no rush so i'll be holding off for now following this thread with interest to see where the consensus leads... taipan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On Wednesday 15 August 2007 3:20:38 pm Jeremy Huntwork wrote: I would love to see some sort of proper support for PM go into LFS, but that all depends on the community... That is what makes LFS so good. I plug it on my blog whenever I get the chance. shameless plug http://blogs.ittoolbox.com/linux/locutus /shameless plug I hate to say it, but I don't recall your system. Do you have a link of some sort? I don't remember exactly when but a quick search on the lfs website turned up this. You will have to search inside the text for it. I do remember making an announcement either on that list or the development list. http://linuxfromscratch.org/pipermail/lfs-chat/2005-May.txt -- Shane Shields Registered LFS Compiler: 7582 To drink the WINE of success you must first seek the sayings of source Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. NOT : Bu mesaj ve ekleri mesajda gönderildigi belirtilen kisi ya da kisilere özel olup gizli bilgiler içeriyor olabilir. Mesajin muhatabi degilseniz lütfen mesaji herhangi bir sekilde kullanmayiniz ve mesaji gönderen kisiyi bilgilendirerek ekleri ile birlikte derhal imha ediniz. Mesaj göndericiye ait olup, Erkunt Tarim Makinalari Sanayii A.S.'nin herhangi bir sorumlulugu bulunmamaktadir.Mesajin size gönderilmesinden, bilgilerin dogrulugundan, bilgisayar sistemine verebilecegi zararlardan ve burada sayilanlar ve sayilmayanlar da dahil dogabilecek tüm zararlardan Erkunt Tarim Makinalari Sanayii. A.S sorumlu tutulamaz. QS Disclaimer Demo. Copyright (C) Pa-software. Visit www.pa-software.com for more information. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Randy McMurchy wrote: Jeremy Huntwork wrote these words on 08/15/07 07:20 CST: I would love to see some sort of proper support for PM go into LFS, but that all depends on the community... I'll go on record as -1. I feel we should mention it, provide links to the various alternatives, and drive on. We are not a distribution. We are a book that shows how to compile Linux from scratch. Let's don't forget that. No, lets not forget that. However, showing an implementation of package management is not in any way detrimental to the education of readers. Package management is beyond the scope of showing how to compile packages (and which packages to compile). I'm not convinced one way or the other. PM is not what makes linux tick, but it may help keep it ticking. --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On Wednesday 15 August 2007 3:20:38 pm Jeremy Huntwork wrote: Shane Shields wrote: On 15 Aug 2007 Wed 11:25 am, Alan Lord wrote: Jeremy - that sounds like a cracking idea but I strongly believe that it should go much further than the LiveCD... Strongly agree I would love to see some sort of proper support for PM go into LFS, but that all depends on the community... The old timers of you may recall that I did do such a complete package management and build system for B/LFS using the RPM package management system. I recall that I did post my scripts and package configuration files for all to use. I too had to (sorrowfully) move to kubuntu as I didn't have the time to single handedly follow LFS, incorporate the package management and keep my system up to date. Perhaps my system could be of use? I hate to say it, but I don't recall your system. Do you have a link of some sort? We had a bit of a discussion in this archive I just found. http://linuxfromscratch.org/pipermail/lfs-dev/2005-October.txt This is where I stored them online :) I don't know if they are my latest but I do have them and LFS ones archived on cd somewhere. http://www.diy-linux.org/downloads/contrib/shane_shields/ -- Shane Shields Registered LFS Compiler: 7582 To drink the WINE of success you must first seek the sayings of source Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. NOT : Bu mesaj ve ekleri mesajda gönderildigi belirtilen kisi ya da kisilere özel olup gizli bilgiler içeriyor olabilir. Mesajin muhatabi degilseniz lütfen mesaji herhangi bir sekilde kullanmayiniz ve mesaji gönderen kisiyi bilgilendirerek ekleri ile birlikte derhal imha ediniz. Mesaj göndericiye ait olup, Erkunt Tarim Makinalari Sanayii A.S.'nin herhangi bir sorumlulugu bulunmamaktadir.Mesajin size gönderilmesinden, bilgilerin dogrulugundan, bilgisayar sistemine verebilecegi zararlardan ve burada sayilanlar ve sayilmayanlar da dahil dogabilecek tüm zararlardan Erkunt Tarim Makinalari Sanayii. A.S sorumlu tutulamaz. QS Disclaimer Demo. Copyright (C) Pa-software. Visit www.pa-software.com for more information. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
david567 wrote these words on 08/15/07 10:56 CST: Randy McMurchy wrote: I feel we should mention it, provide links to the various alternatives, and drive on. We are not a distribution. We are a book that shows how to compile Linux from scratch. Let's don't forget that. No, lets not forget that. However, showing an implementation of package management is not in any way detrimental to the education of readers. Showing an implementation is one thing. Incorporating it into the books is a completely different thing. No comparison. This discussion is about should we incorporate something into the book, not showing readers an implementation. Package management is beyond the scope of showing how to compile packages (and which packages to compile). I'm not convinced one way or the other. PM is not what makes linux tick, but it may help keep it ticking. We've always worked with the underlying philosophy of minimal. Said differently, just enough to create a working bootable system. PM does not fall into that realm. If something were to be implemented, even a DESTDIR foundation without full PM capability, would ruin cut-and-paste capability for the scores of readers that don't want the bloat a PM brings into the picture. -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 11:28:00 up 13 days, 11:19, 1 user, load average: 0.01, 0.06, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Jeremy Huntwork wrote these words on 08/15/07 11:42 CST: Taking this a step further, the commands for most packages could be probably be unaffected entirely if you set DESTDIR to be an environment variable, as in config.site. Note that I haven't tested this. DESTDIR would then have to be cleaned before/after each package. Then we would have a book where if a reader doesn't want to use it, he must not execute some of the commmand(s) on the pages. It could get ugly. However, with some thought and a decent plan, it might be workable in LFS. I can't see it happening in BLFS for the simple reason that it would be a monumental task (automating the proper inserts could perhaps be done, but we wouldn't do that until *every* package has been tested, which again would be monumental). -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 11:54:00 up 13 days, 11:45, 1 user, load average: 0.00, 0.03, 0.06 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev-114 progress with uClibc
On Wed, 2007-08-15 at 10:43 -0500, Kevin Day wrote: Okay, so I finally found out how to make udev's 094 boot under a uClibc system. During the boot process prior to loading/starting udev, I have the following command happening: echo /sbin/udevtrigger /proc/sys/kernel/hotplug This works in udev094, for whatever reason it now causes udev to lock up and not produce proper devices. The end result is system does not boot and sits there. The solution was to change this to: echo '' /proc/sys/kernel/hotplug and suddenly the system boots. I worry that this will cause modules to not be auto-loaded when plugged in. However, this is a step forward into solving the problem. Its quite hard to tell if it will or won't work considering how much udev changes and how much udev has no documentation whatsoever by the udev team. I have always distrusted udev and particularly hated hotplug, and abide them with great unease on any system. It seems my guts were correct ;-). -- With Best Regards, Declan Moriarty. -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On Wed, Aug 15, 2007 at 10:37:44AM -0600, Jeremy Huntwork wrote: Not in the least. If DESTDIR is set to an empty variable, the effect of the command is the same as usual. ./configure --prefix=/usr make make install is the same as ./configure --prefix=/usr make make DESTDIR=$dest install if $dest is empty Taking this a step further, the commands for most packages could be probably be unaffected entirely if you set DESTDIR to be an environment variable, as in config.site. Note that I haven't tested this. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On Wed, Aug 15, 2007 at 11:34:34AM -0500, Randy McMurchy wrote: If something were to be implemented, even a DESTDIR foundation without full PM capability, would ruin cut-and-paste capability for the scores of readers that don't want the bloat a PM brings into the picture. Not in the least. If DESTDIR is set to an empty variable, the effect of the command is the same as usual. ./configure --prefix=/usr make make install is the same as ./configure --prefix=/usr make make DESTDIR=$dest install if $dest is empty -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Jeremy Huntwork wrote these words on 08/15/07 11:37 CST: Not in the least. If DESTDIR is set to an empty variable, the effect of the command is the same as usual. Agreed. I forgot about that. -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 11:42:00 up 13 days, 11:33, 1 user, load average: 0.12, 0.11, 0.09 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Randy McMurchy wrote: david567 wrote these words on 08/15/07 10:56 CST: Randy McMurchy wrote: I feel we should mention it, provide links to the various alternatives, and drive on. We are not a distribution. We are a book that shows how to compile Linux from scratch. Let's don't forget that. No, lets not forget that. However, showing an implementation of package management is not in any way detrimental to the education of readers. Showing an implementation is one thing. Incorporating it into the books is a completely different thing. No comparison. This discussion is about should we incorporate something into the book, not showing readers an implementation. Indeed, the book would need to be the implementation. Package management is beyond the scope of showing how to compile packages (and which packages to compile). I'm not convinced one way or the other. PM is not what makes linux tick, but it may help keep it ticking. We've always worked with the underlying philosophy of minimal. Said differently, just enough to create a working bootable system. PM does not fall into that realm. Adding sustainable/upgradeable is not too far off the mark. If something were to be implemented, even a DESTDIR foundation without full PM capability, would ruin cut-and-paste capability for the scores of readers that don't want the bloat a PM brings into the picture. Agreed, a PM needs to be elegant (simple, robust, and unobtrusive). --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Alexander E. Patrakov wrote: Mike Lynch wrote: One of the nice things about the Solaris package manager is that *every* file installed is registered in a database (just an CSV file so no DB software like SQL needed) so it's easy to find out what has been installed. Package removal references the database to remove files. Furthermore, more than one package or more than one instance of the same package can claim ownership of a file such that removal of a file will not occur until the last package claiming ownership of a file is removed. During removal, only registered files are removed so any user created files remain. Registered directories are only removed if they are empty so if the user adds files to a registered directory after installing a package, package removal will not delete them because they are not registered and the registered directory will then not be removed. This prevents loss of user generated configuration files and the like. This all is also present in Slackware scripts. They also use this feature for upgrades: upgrading means installing the newer package and removing the older version after that. There is a problem that I see from the above description. It may or may not be an actual problem. What about a config file that *is* installed in a package and may be modified by a user? Examples might be /etc/php.ini or /etc/apache/httpd.conf. I wouldn't want these files deleted, even if I deleted the package. My impression of an update is to replace all files that are in the package and that might include user modified files. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
david567 wrote these words on 08/15/07 11:45 CST: Randy McMurchy wrote: Indeed, the book would need to be the implementation. My point exactly. You are suggesting a total implentation, where all we really need to do is explain *how* to implement if the reader wants. Not intrusive that way. Not doing a total implementation does however ruin cut-and-paste for folks that *do* want the framework. But I don't look at that as an issue, as we are not suggesting implementation of a PM, but just a framework for one of many, which means folks are customizing anyway. We've always worked with the underlying philosophy of minimal. Said differently, just enough to create a working bootable system. PM does not fall into that realm. Adding sustainable/upgradeable is not too far off the mark. To me, it is hundreds of miles off the mark. -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 12:00:01 up 13 days, 11:51, 1 user, load average: 0.63, 0.29, 0.15 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Randy McMurchy wrote: I can't see it happening in BLFS for the simple reason that it would be a monumental task (automating the proper inserts could perhaps be done, but we wouldn't do that until *every* package has been tested, which again would be monumental). The 'BLFS' task is already 'monumental'. Let's see what ideas 'emerge' (can say that here?), there's some 'smarts' being devoted to this thread! --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On Wed, Aug 15, 2007 at 11:59:34AM -0500, Randy McMurchy wrote: I can't see it happening in BLFS for the simple reason that it would be a monumental task (automating the proper inserts could perhaps be done, but we wouldn't do that until *every* package has been tested, which again would be monumental). By the same token, once you get past the initial work of adding the PM framework to BLFS, it might make developing and testing BLFS a whole lot easier, simply because of the nature of package managment. But, you're more qualified to speak on whether that's the case than I am. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On Wed, Aug 15, 2007 at 12:05:09PM -0500, Bruce Dubbs wrote: Having said that, I am not opposed to a PM hint (which already exists) or even a entirely new project PM for LFS. A relatively small book that explains package management and one (or more) methods may be a nice compliment to the existing LFS projects. Well, again, the idea of a new project could be manifested in the already existing LiveCD project, especially since that is how we want to manage our development. It could become more effectively the 'distro' of LFS. The focus wouldn't be on packaging and distributing every piece of software imaginable, but what we need for the CD, and of course showing how to make compatible packages of your own. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Randy McMurchy wrote: Jeremy Huntwork wrote these words on 08/15/07 11:42 CST: ~snip~ I can't see it happening in BLFS for the simple reason that it would be a monumental task (automating the proper inserts could perhaps be done, but we wouldn't do that until *every* package has been tested, which again would be monumental). maybe, but BLFS is probably where inclusion of a package manager of some sort would be best placed. The biggest issue with pms is the number of options. trying to put into any of the books a pm without picking one is not an easy task. yet the workload of having sections for every pm is way to much. I think adding the destdir to the build commands, as an option to enable pm use in blfs, might be the best option for lfs itself. The real headache of the pm is that unless the entire collection of editors and testers were to start collecting updates and rating for security / bugfix / regular new version and testing them, any pm installed on an lfs based system is only 1/2 as usefull as intended. ( at best ) Does anyone on the list have the time to monitor the packages and test the patches, then make update packages for every pm option? The distros have sufficient staff / volunteers to do it, for their pm choice, does the LFS project for all pms? Your Distro, Your Way If the editors pick a pm, then they are removing the choice part of that. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On Wed, Aug 15, 2007 at 07:07:40AM -0600, Jeremy Huntwork wrote: On Wed, Aug 15, 2007 at 07:37:12AM -0500, Randy McMurchy wrote: I'll go on record as -1. I'm not going to push to get this into LFS. If the vast majority of those with a voice here are for PM in LFS, great. If not, great. :) I'm going to tentatively vote -1 for package management in LFS -- that is, unless it doesn't break my current package management setup (pkg-user hint FTW!). If the changes don't break the pkg-user hint, then I'd say +1; it's worth a shot at least. DESTDIR=$dest on all the packages, for instance, shouldn't hurt if $dest is empty. And I'd bet that most users would appreciate the book working with some kind of package manager (as that seems to be the proposal). For the LiveCD, I think it's a pretty good idea to use some fixed package management, basically because it's limited in scope (just the livecd image that you're going to build), and it makes life a lot easier for the devs. The cost seems fairly low (assuming the livecd devs can agree on an implementation... ;-) ), and the benefit seems pretty high. pgpU1R9KXKxEO.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Jeremy Huntwork wrote these words on 08/15/07 12:06 CST: By the same token, once you get past the initial work of adding the PM framework to BLFS, it might make developing and testing BLFS a whole lot easier, simply because of the nature of package managment. But, you're more qualified to speak on whether that's the case than I am. I (and I believe Dan as well, that I know of), already use a DESTDIR approach. I don't believe in doing otherwise with unknown packages. Not doing it exposes you to a multitude of bad things. I realize I'm making a case for using it saying the above, however, I don't feel we need to push it onto users. Merely suggesting it, *and letting the reader make the choice to do it or not*, should be more than ample. The readers should take for granted our instructions have been scrutinized and tested, and they should feel confident these bad things won't happen. -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 12:33:01 up 13 days, 12:24, 1 user, load average: 0.75, 0.18, 0.10 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On Wed, Aug 15, 2007 at 12:38:26PM -0500, Randy McMurchy wrote: I realize I'm making a case for using it saying the above, however, I don't feel we need to push it onto users. Merely suggesting it, *and letting the reader make the choice to do it or not*, should be more than ample. The readers should take for granted our instructions have been scrutinized and tested, and they should feel confident these bad things won't happen. I wholeheartedly agree with the above. I guess the difference in our viewpoint is that I don't see adding a 'DESTDIR=' setting to the install commands or environment variable as pushing it on the user. They get the choice as to whether or not they fill that. And if they do, it's up to them to make sure that directory is clean before they install it, and then what PM to use to package it up/install it. What I do like about it is that it adds a useful feature (for some), offers flexibility, and offers areas for greater education. It could be argued that by inspecting the contents of DESTDIR after they run the make install command there is additional opportunity for builders to get familiar with what exactly is going to be installed. Again, please don't take the above as me pushing to get this in to LFS. I'm just stating my personal views as to its usefulness. Even without it, LFS and BLFS are great. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Randy McMurchy wrote: david567 wrote these words on 08/15/07 11:45 CST: Randy McMurchy wrote: Indeed, the book would need to be the implementation. My point exactly. You are suggesting a total implentation, where all we really need to do is explain *how* to implement if the reader wants. Not intrusive that way. Not doing a total implementation does however ruin cut-and-paste for folks that *do* want the framework. But I don't look at that as an issue, as we are not suggesting implementation of a PM, but just a framework for one of many, which means folks are customizing anyway. Agreed. We've always worked with the underlying philosophy of minimal. Said differently, just enough to create a working bootable system. PM does not fall into that realm. Adding sustainable/upgradeable is not too far off the mark. To me, it is hundreds of miles off the mark. I'm not sure which of us is the devil's advocate. 'Unix and C, the ultimate virus!', long live LFS! David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Jeremy Huntwork wrote: On Wed, Aug 15, 2007 at 10:17:51AM -0700, lists wrote: If the editors pick a pm, then they are removing the choice part of that. And for that reason I think I would be against adding a specific PM to LFS/BLFS. However, dropping in a DESTDIR framework would allow for *most* package managers to be used without adding any further specifics. Which is not an issue for me. setting it up as an environment variable as with $LFS but making it clear that this optional variable is only needed to make package manager usage easier to implement if they want seems a good resolution for LFS. At this point, whether or not LFS or BLFS decide to use DESTDIR (or anything else) isn't as important to me as getting the proper setup in place for the LiveCD. :) Which would make maintaining the LiveCD far simpler for everyone involved. :) Since my involvment is limited to testing the LiveCD, not in maintaining it, whichever one works for the maintainers is the best option. ;) Jaqui -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Bryan Kadzban wrote: I'm going to tentatively vote -1 for package management in LFS -- that is, unless it doesn't break my current package management setup (pkg-user hint FTW!). If the changes don't break the pkg-user hint, then I'd say +1; it's worth a shot at least. DESTDIR=$dest on all the packages, for instance, shouldn't hurt if $dest is empty. Obviously $dest must be chgrp install chmod 1775 in such a case, but beyond that i found it actually _improved_ on the pkgusr method - it even negates one or two of the gremlins mentioned in the hint, allows for additional install-dir's to be correctly created when needed, like during X-installation. There are a couple of packages in LFS that don't play nice with $DESTDIR (i think 'shadow' was one), but hopefully more adept minds than mine would be able to resolve those issues, if this proposal goes forward... taipan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Jeremy Huntwork wrote: What I do like about it is that it adds a useful feature (for some), offers flexibility, and offers areas for greater education. It could be argued that by inspecting the contents of DESTDIR after they run the make install command there is additional opportunity for builders to get familiar with what exactly is going to be installed. -- JH That's precisely what i'd hoped to say in my initial post in this thread, when i said that the use of $DESTDIR wouldn't detract from the book's educational objectives - on the contrary, it would more likely be an enhancement. Thank you, Jeremy, for your superior eloquence. ;-) taipan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Fwd: New LiveCD master server
Meant to CC this to lfs-dev for the sake of visibility. - Forwarded message from Jeremy Huntwork [EMAIL PROTECTED] - To: [EMAIL PROTECTED] From: Jeremy Huntwork [EMAIL PROTECTED] Date: Wed, 15 Aug 2007 12:05:45 -0600 User-Agent: Mutt/1.5.11 Subject: New LiveCD master server Hello all, I've mentioned previously that this was coming, but as of now there is a new server for the LiveCD project that should be considered upstream. We'd like to keep as many of the current mirrors as possible, but the source of fresh isos will now be this new server. Working this way will make it easy for any LiveCD dev to publish ISOs as all have shell access. HTTP: http://kerrek.linuxfromscratch.org/pub/ Anonymous FTP: ftp://kerrek.linuxfromscratch.org RSYNC: rsync -av --delete kerrek.linuxfromscratch.org::livecd I'll be updating the site to reflect the above shortly. First I need some food... :) Also, we'd like to glean an updated list of current livecd mirrors, so if you are one, please update your scripts to use the above server and send me a private note with your info. Thanks -- JH -- http://linuxfromscratch.org/mailman/listinfo/livecd FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page - End forwarded message - -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On Wednesday 15 August 2007 8:53:23 pm Jeremy Huntwork wrote: offers areas for greater education. It could be argued that by inspecting the contents of DESTDIR after they run the make install command there is additional opportunity for builders to get familiar with what exactly is going to be installed. I think that this is an extremely important point. The whole point of LFS is education and omitting this is a lack in the book IMHO. However on the other hand some packages do not support DESTDIR or use a different variable and could cause more confusion and support requests. -- Shane Shields Registered LFS Compiler: 7582 To drink the WINE of success you must first seek the sayings of source Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. NOT : Bu mesaj ve ekleri mesajda gönderildigi belirtilen kisi ya da kisilere özel olup gizli bilgiler içeriyor olabilir. Mesajin muhatabi degilseniz lütfen mesaji herhangi bir sekilde kullanmayiniz ve mesaji gönderen kisiyi bilgilendirerek ekleri ile birlikte derhal imha ediniz. Mesaj göndericiye ait olup, Erkunt Tarim Makinalari Sanayii A.S.'nin herhangi bir sorumlulugu bulunmamaktadir.Mesajin size gönderilmesinden, bilgilerin dogrulugundan, bilgisayar sistemine verebilecegi zararlardan ve burada sayilanlar ve sayilmayanlar da dahil dogabilecek tüm zararlardan Erkunt Tarim Makinalari Sanayii. A.S sorumlu tutulamaz. QS Disclaimer Demo. Copyright (C) Pa-software. Visit www.pa-software.com for more information. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Jeremy Huntwork wrote these words on 08/15/07 12:53 CST: What I do like about it is that it adds a useful feature (for some), offers flexibility, and offers areas for greater education. It could be argued that by inspecting the contents of DESTDIR after they run the make install command there is additional opportunity for builders to get familiar with what exactly is going to be installed. You are indeed correct. But I would bet that 90% (probably higher) of the readers wouldn't even look in DESTDIR, instead just blindly copying and pasting the commands and going on their merry way building a system. Again, please don't take the above as me pushing to get this in to LFS. I haven't and wouldn't. I understand the nature of 'discussion'. As long as things don't get personal, a discussion is just folks expressing opinion and the foundations behind that opinion. Though I have a short memory, I haven't seen things get personal on an LFS list in a long time. I'm just stating my personal views as to its usefulness. As I hope you continue to do for years to come. :-) -- Randy rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 13:01:00 up 13 days, 12:52, 1 user, load average: 0.18, 0.14, 0.10 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
On Wednesday 15 August 2007 3:20:38 pm Jeremy Huntwork wrote: I hate to say it, but I don't recall your system. Do you have a link of some sort? I did post a couple of replies with links in them but they may have been considered spam and they don't seem to have gotten through. You can look through the October 2005 lfs-chat archives for the relevent information. -- Shane Shields Registered LFS Compiler: 7582 To drink the WINE of success you must first seek the sayings of source Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. NOT : Bu mesaj ve ekleri mesajda gönderildigi belirtilen kisi ya da kisilere özel olup gizli bilgiler içeriyor olabilir. Mesajin muhatabi degilseniz lütfen mesaji herhangi bir sekilde kullanmayiniz ve mesaji gönderen kisiyi bilgilendirerek ekleri ile birlikte derhal imha ediniz. Mesaj göndericiye ait olup, Erkunt Tarim Makinalari Sanayii A.S.'nin herhangi bir sorumlulugu bulunmamaktadir.Mesajin size gönderilmesinden, bilgilerin dogrulugundan, bilgisayar sistemine verebilecegi zararlardan ve burada sayilanlar ve sayilmayanlar da dahil dogabilecek tüm zararlardan Erkunt Tarim Makinalari Sanayii. A.S sorumlu tutulamaz. QS Disclaimer Demo. Copyright (C) Pa-software. Visit www.pa-software.com for more information. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
taipan67 wrote: Bryan Kadzban wrote: I'm going to tentatively vote -1 for package management in LFS -- that is, unless it doesn't break my current package management setup (pkg-user hint FTW!). If the changes don't break the pkg-user hint, then I'd say +1; it's worth a shot at least. DESTDIR=$dest on all the packages, for instance, shouldn't hurt if $dest is empty. Obviously $dest must be chgrp install chmod 1775 in such a case... snip taipan Actually, the sticky bit isn't really necessary, since the package-user would be doing rm -r $dest/* after relocating the files to the live system, thus leaving it empty. Also, still slightly OT (sorry), i've been using strip --strip-unneeded instead of strip --strip-all on the binaries in $dest, as 'man strip' says something about 'relocation symbols' - i don't understand it entirely, but figured better safe than sorry, plus it's what portage does... taipan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 taipan67 wrote: Bryan Kadzban wrote: DESTDIR=$dest on all the packages, for instance, shouldn't hurt if $dest is empty. Obviously $dest must be chgrp install chmod 1775 in such a case, The case where $dest is empty? :-P but beyond that i found it actually _improved_ on the pkgusr method - it even negates one or two of the gremlins mentioned in the hint, allows for additional install-dir's to be correctly created when needed, like during X-installation. Oh: you're setting it up so the package user uses a non-empty DESTDIR, then moves the files into the real system? That's an interesting idea; hmm. I'm not seeing where it would matter much; can you be more specific on some of the gremlins that this helps with? Or aren't you moving the files as the package user? I'd think you'd have to... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGw3xtS5vET1Wea5wRAxcCAKCs4Ej74kzy6nIIvvNfnTygTrVeoACgrPXy Jfnu7XQjMRJB9JUUkfYGJRE= =ZrQ1 -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Inconsistent use of in BOOK
On Tuesday 24 July 2007 07:56, Dan Nicholson wrote: ... and noticed some in chained commands. It seems that usual way in LFS is not to do this. Curious; is this just a style preference? I notice in Chapter 5 Adjusting the Toolchain: - GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file-name)`/include find ${GCC_INCLUDEDIR}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \; rm -vf `grep -l DO NOT EDIT THIS FILE ${GCC_INCLUDEDIR}/*` unset GCC_INCLUDEDIR - And it could be replaced a bunch of ways: 1. - ( GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file-name)`/include find ${GCC_INCLUDEDIR}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \; rm -vf `grep -l DO NOT EDIT THIS FILE ${GCC_INCLUDEDIR}/*`; ) - This one would ensure that GCC_INCLUDE is unset in the event of a failure, probably not a big deal. Or, if a subshell is to be avoided: 2. - GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file-name)`/include find ${GCC_INCLUDEDIR}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \; rm -vf `grep -l DO NOT EDIT THIS FILE ${GCC_INCLUDEDIR}/*` unset GCC_INCLUDEDIR || unset GCC_INCLUDE - 3. - Or, maybe just strip the ''s right out of there; I'm not sure how other browsers and consoles work, but with my combo a cut and paste without the works just fine I just have to hit enter for the last command; this also keeps the screen output tied to the commands. 4. - And finally, if there is no intention to use the '' as a control character replace it with ';' and the unset will be fine. Personally, I like the first one best. In the even that GCC_INCLUDEDIR fails to set the following command won't go around trying to delete all directories off the root. I played; I did; luckily I was quick with the crtl-c and not root and only ended up deleting part of an old home directory... Now I have a user for playing with these things ;). Trent. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: A call for help
Craig Jackson wrote: I would love to help. I do have a couple of questions so we can hopefully be more effective at this. Hi Craig. Thanks for the reply! 1. What are some examples of common issues that users have reported that you feel would benefit from a bit of automated testing? There will always be a need for ad-hoc, but automation can help with some of the more trivial sanity checks. Well, the first thing that springs to mind is jhalfs. It seems that many users jump right in to the automation, and if they haven't (or sometimes if they have) used it before they'll hit some sort of wall. I'm hesitant to provide too much guidance with jhalfs, because I'm afraid of helping new ones miss the purpose of LFS entirely by doing so. That said, it is always nice to have someone test the included versions of the LFS xml, jhalfs, and the source packages to make sure that everything runs without a hitch. I'm not sure how to automate the testing of other aspects of the CDs, but you could look at the included packages and see if you can't figure out something yourself. :) Other than that, to me, the biggest issue is hardware. We'd like to see it tested on as many machines as possible. 2. I could work on scripts that do some basic sanity checks at runtime, but if that's already in place I could focus on some more feature-specific problem areas. Feel free to draw something up. Nothing like that exists as of now that I'm aware of. 3. Is it safe to assume that the results of testing the binaries and other files included in the minimal version should also apply to the X version? In other words, are the X+XFCE additions simply appended, or are modifications of the minimal cd required to build the X cd? This way, tests on the binaries in the minimal cd won't have to be run against the X cd since they have already been done in the minimal cd. (I hope I'm not too confusing here) In theory, yes. In practical terms, we don't have a method in place (yet) to ensure that both systems are using binaries that are 100% alike. With the new development model we should be able to achieve that. 4. If it is decided that the LiveCD will have a package manager, how much can this be relied on when dropping in different versions of {libraries,binaries}? I'm not quite sure what you mean here, but I get the feeling that a lot of these questions will be answered once we have the new model in place. I'm about to draw up another email that lists some more details about how I'd like to see development happen on this project, so stay tuned. In the meantime, I guess I will get the latest dev release and poke around a bit more than I have in the past to get some ideas. Yes, that would give you a heads start, though again, much of our current setup may change in the near futre. Alexander may also have some feedback for you, but as I said, perk up your ears for more discussion on the new model. That should hopefully make all of the above easier. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: A call for help
* Developers to experiment with and present new concepts for the CDs * Maintainers to help build the CDs, correct flaws in the build scripts, update (and test) existing software included on the CDs * Testers to download the isos, run as much of the software on as wide a range of machines as they can, and report. Yes, please report both successes and failures * Editors to help write and maintain documentation for various aspects of the CDs Hello Jeremy, I would love to help. I do have a couple of questions so we can hopefully be more effective at this. 1. What are some examples of common issues that users have reported that you feel would benefit from a bit of automated testing? There will always be a need for ad-hoc, but automation can help with some of the more trivial sanity checks. 2. I could work on scripts that do some basic sanity checks at runtime, but if that's already in place I could focus on some more feature-specific problem areas. 3. Is it safe to assume that the results of testing the binaries and other files included in the minimal version should also apply to the X version? In other words, are the X+XFCE additions simply appended, or are modifications of the minimal cd required to build the X cd? This way, tests on the binaries in the minimal cd won't have to be run against the X cd since they have already been done in the minimal cd. (I hope I'm not too confusing here) 4. If it is decided that the LiveCD will have a package manager, how much can this be relied on when dropping in different versions of {libraries,binaries}? In the meantime, I guess I will get the latest dev release and poke around a bit more than I have in the past to get some ideas. Thanks! Craig Jackson (TheEpitome) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Resolution (was Re: jh-branch)
Greg Schafer wrote: The facts are, our current native build method relies on the ability to link against the host libc with the target ld. There is nothing inherently wrong with this approach because it should always work in typical LFS build scenarios (barring bugs of course). Yes, it would probably be better if we could avoid it somehow, but the build method would need to change radically in order to achieve this - cross compilation, gross hacks, whatever. Hmmm, thinking about this some more, there might actually be another option and that's the one already raised by Alex ie: don't bootstrap GCC pass1 (possibly move the bootstrap to pass2 as suggested by Jeremy). As it currently stands, the new tools start being used in combo with the host glibc during stage2 of the bootstrap. We could avoid this by dropping the bootstrap of pass1. That leaves the only exposed areas as kernel headers installation and glibc configure, but if they cause problems, we might be able to get away some PATH twiddling. There might be some merit here.. I'll chew on it for a while and maybe try some tests. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Jeremy Huntwork wrote: And for that reason I think I would be against adding a specific PM to LFS/BLFS. However, dropping in a DESTDIR framework would allow for *most* package managers to be used without adding any further specifics. At this point, whether or not LFS or BLFS decide to use DESTDIR (or anything else) isn't as important to me as getting the proper setup in place for the LiveCD. :) OK. Here are some more details that have been rolling about in my head as to how LiveCD development might proceed. Thoughts very welcome: * Temporary tools a la LFS chapter 5 produced and stored on kerrek.linuxfromscratch.org. I can set this up to be done automatically whenever there is a change to chapter 5, or chapter 5 package versions. This gives us a nice place to start from. * Packages and their build logs also reside at kerrek. Developers preparing to work on the CD could perhaps make use of rsync to update their local working area before starting any software builds. * Config.site is employed to ensure a consistent environment when building. For x86, all pieces of software should be targeted at i486. Also, as much as possible, we stick to LFS build methods, order and versions for the version of LFS book at which the CD is targeted. * Tracking Dependencies. There's much to discuss here. First of all, I can't recall from pkgtools, but does Pacman help track dependencies similar to RPM? That may be one advantage of making use of RPM. Whatever package manager we use, we want to be able to track how packages are affected. My hope is to avoid as much as possible, the long builds of the CD that we currently have, and to make the production of the CD a simple matter of installing the system to a working directory using pre-built packages and rolling up an ISO. So, if for example, there is an updated version of Openssl, we'll want to know what packages link against it so that those can be built against the new version. It would be nice if we had a system whereby we can flag one package for update, and all those after it in the dependency tree would be flagged as well. Is this making sense? * Lastly, we need to write recipes in the form of scripts that will properly set up a working environment, grab the necessary binary packages, install them and create the ISO. I'm still having some trouble seeing exactly how much of this will take shape. Hopefully the above will spark some other ideas and discussion. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Resolution (was Re: jh-branch)
Greg Schafer wrote: Hmmm, thinking about this some more, there might actually be another option and that's the one already raised by Alex ie: don't bootstrap GCC pass1 (possibly move the bootstrap to pass2 as suggested by Jeremy). As it currently stands, the new tools start being used in combo with the host glibc during stage2 of the bootstrap. We could avoid this by dropping the bootstrap of pass1. That leaves the only exposed areas as kernel headers installation and glibc configure, but if they cause problems, we might be able to get away some PATH twiddling. There might be some merit here.. I'll chew on it for a while and maybe try some tests. Funny that you mentioned this tonight. I was going to test that setup on the jh branch tonight if I had the time. Looking forward to seeing the results of your tests. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Resolution (was Re: jh-branch)
Greg Schafer wrote: I'll chew on it for a while and maybe try some tests. Greg, Looking at gcc-4.2.1's configure, I see that --enable-bootstrap seems to be the default if we are building native. I'm trying to read what I can, but perhaps you know the answer already. Does this mean that GCC by default is doing what it used to do when calling 'make bootstrap'? I.e., is it unnecessary to specify 'make bootstrap' for gcc-4.2.1 if we want to bootstrap and alternately, if we don't want to bootstrap we have to set --disable-bootstrap? Or is there more going on behind the scenes? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Resolution (was Re: jh-branch)
Greg Schafer wrote: This is all covered in the DIY Refbuild doc. Pls read it. I need to keep make bootstrap because I support multiple versions of GCC with the one set of build commands. Yep, thanks. I saw that you used --disable-bootstrap the last time I visited, but missed the note. I should have looked there again before asking... Thanks for the reply. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Bruce Dubbs wrote: There is a problem that I see from the above description. It may or may not be an actual problem. What about a config file that *is* installed in a package and may be modified by a user? Examples might be /etc/php.ini or /etc/apache/httpd.conf. I wouldn't want these files deleted, even if I deleted the package. Slackware packages never ship configuration files that are supposed to be modified by end users. Instead, such configuration files are shipped with the .new extension, and a post-installation script handles this. E.g., for udev: #!/bin/sh config() { NEW=$1 OLD=`dirname $NEW`/`basename $NEW .new` # If there's no config file by that name, mv it over: if [ ! -r $OLD ]; then mv $NEW $OLD elif [ `cat $OLD | md5sum` = `cat $NEW | md5sum` ]; then # toss the redundant copy rm $NEW fi # Otherwise, we leave the .new copy for the admin to consider... } config etc/rc.d/rc.udev.new config etc/modprobe.d/blacklist.new config etc/modprobe.d/isapnp.new As you see, the real etc/modprobe.d/blacklist configuration file does not belong to any package and thus will not be removed automatically. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page