Re: An idea for a new development model
From: Alexander E. Patrakov [EMAIL PROTECTED] Walter Barnes wrote: Has anyone considered using unionfs to create a fake root? Yes. The 6.1 CD was based on unionfs. Unionfs produces kernel oops if stress-tested or on SMP. Also, glibc testsuite doesn't pass if /tmp is on unionfs. So this package is now blacklisted. Well that's not good. But thanks for the heads up. I was working on a package manager based on unionfs; I'll have to go back and rethink whether or not it's worth the effort. Maybe aufs performs better. As for the glibc issue, I can try restricting use of unionfs/aufs to 'make install'. It's only really needed for that anyway. Thanks, Walter Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222 -- 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/16/07 00:51 CST: 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. This to me is way, way beyond the scope of what we do. If it ends up that we want to do something like this, I would hope it would be a separate branch, with the main thrust continuing with what we currently do. To me, there simply isn't enough development staff to attempt to be a distribution. On the LFS side, with 2-4 devs, it would be doable, in BLFS right now with the current staff, impossible. Just offering thought, so don't think I'm totally being negative, nor arguing against the idea. I'm just thinking that it adds such an enormous effort on top of what we already do, that it would soon seem insurmountable trying to keep up. -- Randy rmlscsi: [bogomips 1003.22] [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] 00:59:00 up 4 min, 1 user, load average: 0.24, 0.42, 0.19 -- 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
I'd like to give my opinion and 2 cents worth to this topic, even if I'm not a regular member or contributor. I've been reading the forums more regularly recently. I came across LFS 3 - 4 years ago, when I got upset with all other distributions that I had tried. Upset mainly because of their PM systems. But not so much their functionality (Debian's apt is great), but because of their dependency resolution, or lack thereof. Now, by lack thereof I don't mean that they don't resolve; they do, but the dependencies, especially for packages like GNOME or KDE, are horrendous, and not all of them necessary, as the BLFS book shows. Personally, I want a lean, fast and stable system, and when I add an application, I don't want to add 20 others, because there might be some optional things, etc. Even if you use a PM to add kdebase or the gnome core packages, you'll see an enormous list of dependencies and upon checking, you'll find that you don't need all of them. But the result is that your system gets bloated and runs more and more processes. One of the main reasons that I come back to LFS all the time and rebuild, because I've tried so many distros and none of them has really convinced me with regards to PM package dependencies. So even though the educational benefits of learning how to build LFS and a Linux system in general, aren't that big anymore, I still prefer LFS. But admittedly, I don't always have the time to rebuild or build new packages and optional applications and using a PM is more comfortable and quicker. Personally, I've tried DESTDIR and it works fine, except for the odd packages that ignore it. Because of that, when I can't be bothered investigating whether a package supports it or not, I fall back to simply building the package in the normal way and then just looking at the difference in files created on the file system. Yes, maybe not the most advanced way, but it works smoothly. Takes a bit more time because you have to wait a bit between builds, but hey. And I've created and am still creating scripts to automate builds and that will resolve build dependencies. Works well, except for the dependencies yet. My thoughts after that were to create some kind of PM, whether source based or binary based or both. With regards to whether or not a PM should be part of LFS, I am taking the pragmatic approach. So, it doesn't necessarily have to. I would almost go as far as to say that the Linux world is spoiled by having a PM (while I am aware that this is probably one of the reasons why it has grown in popularity), because look at Windows or Mac OS X. Where's their PM? And people are still using these OSs. Mac OS X is a great OS, and it comes pre-packaged with most things you need. If you want more, you go and search and find it (yes, I know there's fink, etc.). OK, this might be a bit OT, but I wanted to give my input here as well, as I'm trying to give more to the LFS community. I've actually had thoughts of going towards an LFS based distribution, because I'm getting so upset with other distros, that would offer you a lean and fast environment, with a DE of choice and all the necessary applications to do your day to day business. But not five of each ... I don't want/need 5 different word processors or chat applications or the like; just want one that works well and is well integrated. Part of that distro could be a PM, although I personally don't think that to be so much of a big topic, if the rest of the distro offers everything you need, is not bloated and runs smoothly. Any thoughts on this welcome and I hope I didn't intrude on this topic too much. ___ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00 -- 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: Alexander E. Patrakov wrote these words on 08/16/07 00:51 CST: 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. This to me is way, way beyond the scope of what we do. If it ends up that we want to do something like this, I would hope it would be a separate branch, with the main thrust continuing with what we currently do. Sure. We won't do this, because this is specific to Slackware package manager. My intention was to demonstrate to Bruce how this works, not to suggest this for the book as a mandatory part. Other package managers have a different approach to handling configuration files. E.g., RPM and dpkg support them natively, provided that they are marked as such in the spec file or listed in the debian/conffiles file. However, we should do a common part that applies to all package managers: for each package, identify and list (as we do, e.g., for installed libraries) configuration files (i.e., files that are supposed to be changed after installation by the end user or by a script that comes with a package). -- 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
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: 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
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: 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
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: 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: 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
An idea for a new development model
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.
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.
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.
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.
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.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
