On 07/14/2011 02:01 AM, DJ Lucas wrote: >>>> Gnome section at the same time. >>> Actually, there was a very good reason for our divergence, and it's one >>> I've been complaining about for a long time. This problem falls back to >>> LFS. There is no package management so we, as editors, tend to go about >>> managing things differently. >> The whole point of LFS is that it doesn't have package management. > <Snip> > Actually, you've missed the point, likely you didn't take part in the > previous discussion on LFS-Dev (~January maybe?).
Nope, I check the archives about once a year, but only bothered to subscribe now. (Well, I was subscribed to ALFS circa 2001, CLFS since 2006-ish... But mostly hanging around the edges and reading through release versions.) > I'll get you a link > when I get back in if somebody doesn't beat me to it. LFS's goal is to > teach, and that includes managing your system once installed. Yes, there's been a section in the book on that for a while. Personally I found the berkeley style init script hint back around 2002 and stopped paying nearly as much attention to the more complicated system setup you guys do ever since. (I've been meaning to write an Embedded Linux From Scratch for years. The smallest self-bootstrapping system is linux, binutils, gcc, busybox, uClibc, make, and bash. The trick is connecting them together correctly. :) > The proposed 'packaging' doesn't actually produce a package, Isn't there a section of the base LFS book discussiong a half-dozen options you could be doing here? (I actually implemented the timestamp-based one in my scripts, I just never bother to enable it unless I'm regression testing that it still works.) > only installs > to DESTDIR to lend a hand in packaging or file system accounting. The > real installation is done from DESTDIR to the root so that all > post-install steps are included in the book. I did a POC back in 2008 > with just shell scripts, and I'm mostly done with an actual book I > haven't put up yet, but it's ugly with the lib64 -> lib hack (and a few > months out of date now). I'd actually like to propose reversing that > symlink at some point as it'll keep from having to pre-create the dirs > and symlinks in DESTDIR prior to installation for most packages. I'm building a dozen targets and only x86-64 tries to install stuff in lib64. I create a temporary lib64->lib symlink during the gcc build and then delete it again after gcc finishes crapping into it. >>> One of those management issues is the /usr >>> vs /opt debate. I want to drop the /opt anything in BLFS proper and let >>> package management do it's thing. >> I haven't build a system with /opt on it in almost 10 years. >> >>> Everything goes into /usr or / now >>> (and this may even change in the near future on the new standards as >>> /usr might go away). >> Define "might". Do you have evidence that the Linux Standards Base is >> planning to suddenly break compatability with the history of Unix going >> back to 1972? Is there any reason for it? > Yeah, I do have evidence. We are already breaking the current rules WRT > FHS; have been for a bit now for udev...and we're already headed in that > general direction. The proposed changes are in FHS, not LSB, but for > which LSB will follow. >> (Oh, but /opt is better than /usr because nobody uses it therefore it >> isn't cluttered! If you "mv /usr /opt" the clutter magically clears >> itself up and starts to scale.) > Review the current FHS bugs and discussions if you have the available > time to search for them. I'll find and post links when I get back if not. Every once in a while I'll be at a conference where the Ubuntu guys vent at the Linux Foundation guys for requiring RPM in something yet again or whatever strange transgression they've done this time, and I'll get an update on the new craziness in the "standards". But I don't really seek them out. I regression test packages against a layout and if it works, life is good. If it doesn't work, I fix it for the packages, not for the standard. (I pay attention to SUSv4, but thought FHS was a Red Hat Enterprise thing required by Fortune 500 types.) LSB/FHS in particular have never been worth following. On more than one occasion the Linux Foundation guys have forgotten that http://refspecs.freestandards.org even _exists_ and I've had to email them about broken links. (Yeah, OSDL and FSG merged to form a voltron of bureaucracy, but as far as I can tell the real motivating factor was to collect all the money IBM and Intel and such were donating into one bank account, not for any _functional_ reason.) I prefer to understand _why_ things are done a certain way. The /usr directory exists because Ken and Dennis ran out of space on their original RK-05 disk pack circa 1971 and leaked the OS into the second disk which stored user account directories. When they got a third disk pack they mounted it on /home and moved the user accounts there, and kept the OS scattered across the original pair of 2.5 megabyte disks they aleready had. (And then when they did plan 9, they made union mounts available to normal users and did away with the idea of $PATH entirely.) This was always historical scar tissue that _never_ applied to Linux, but people continued to make a distinction on what goes in /bin vs /usr/bin based on what you needed in early boot for a decade after Linux introduced initrd (let alone initramfs), because they didn't know WHY it had been done that way so they could never question what they'd been told. (Computer history is a hobby of mine, because I want to know why it was done that way.) Personally, I symlink /bin to /usr/bin and so on with /sbin and /lib. I'm not recommending it, I'm just saying I know why it works. (And why things like #!/paths and the library loader absolute path prevent you from having just one without the symlink.) *shrug* Good luck with it. >>> Taking the gnome example, >> I don't care about gnome. I want to ignore Gnome. Making gnome part of >> the giant hairball that is BLFS doesn't make a lot of sense to me. >> > Ouch! That was pretty damn careless! You just dismissed a few thousand > hours of work, work done by most of the authors in this very thread. Wow, chapters 33 and 34 absorbed _thousands_ of hours of work? No wonder the rest of the book has languished without a new release for almost three years. All the activity is in an obscure corner. That sounds like an argument in favor or breaking it up to me. (I speak from experience: by the time I created a separate buildroot mailing list and kicked the traffic over there, the uClibc mailing list had been swamped by non-uClibc development traffic for a couple years. The project still hasn't fully recovered, but at least non-buildroot developers can participate again without feeling out of place.) > I'll give you the benefit of the doubt and assume that your thoughts > didn't translate well into text. Please elaborate. BLFS is interesting to me because it shows how to build x.org if I want a graphical system (used to be one package, now something like 35 you have to do in order. I can figure out how to layer fvwm or fluxbox or xfce on top of that myself if necessary, although docs on this would be nice.) If I want to build a network server, a different part of BLFS is useful. The fact they're in the same project is irrelevant to me, I don't think I've ever put them both in the same system. (When I need that I just use Gentoo or something instead of LFS. Keeping such a complex system _updated_ isn't worth it without automation.) I'm glad the current BLFS isolates Gnome support to a section I don't have to read. If gnome was a requirement, BLFS would hold zero interest for me. (I just cut three paragraphs of "elaborating" on why I don't like Gnome, but it's not particularly relevant. I _do_ like the rest of BLFS or I wouldn't bother to post here.) > <Snip> > >> >>>> By considering a branch broken, it would encourage >>>> people to submit changes. >> On what planet? >> >> Branches are so convenient because they're easy for everyone else to >> ignore. The ones that label themselves as not working up front are >> trivial to ignore. >> > But at least there is some activity. You hinted at that yourself earlier > about time based releases and what it means to a user's perception. I remember the JOS project. (Open source javaOS.) It had tons of repo activity. Never got out a release. The project died. uClibc had constant repo activity between NPTL first going in the tree in 2006 and today, but had huge trouble translating that to releases for a number of reasons. (The "project tumor" problem with buildroot, and also because they wanted to replace pthreads with nptl on all targets when they shipped NPTL support. The NPTL branch didn't work on x86-64 a couple months before the 0.9.32 release that finally got it out this year, because apparently nobody had ever bothered to TRY it.) During this time, klibc and eglibc started up to fill a perceived vacuum brought about by the supposed death of uClibc. Thrashing is not activity. Repository commits that never result in a release mean the developers are off in a corner masturbating. (P.S. I'm not implying a "project tumor" can't be valuable, fabrice bellard abandoned tinycc to do qemu and that's a great project. But tinycc development never recovered: http://bellard.org/tcc/tccboot.html was 2004 and these days they're _further_ from being able to build a working linux kernel than they were back then.) > It is a place to start working toward getting something included in the > main book (or books, though I don't particularly see any benefit in that > proposal, seems like more work rather than less, more later). I can do a git repo right now, on my laptop. I don't need permission, I can host it anywhere, and if you decide you like it you can pull from it. That's how git works. >>> I'd like to take this a step further. *ANYBODY* who wants a branch, gets >>> one. >> Um, that's how distributed source control works. It's inherent in it >> being distributed source control. You proposed moving to git, so you >> get that. It's not a separate point. >> > Not exactly what I was getting at, I meant on LFS server, Why? (Do they have to get an email address on linuxfromscratch.org in order to subscribe to the mailing list? What purpose does this serve?) > but I suppose > anybody could use a service like github or what not to make their > dirivative works publicly available just to lower the bar for entry. That's how distributed source control works. (That's the "distributed" part.) Then if you want to accept their changes, you pull them (or cherry-pick them) into your tree, and have the external tree rebase. > Of course their own servers are an option, just not the low bar of entry I > was shooting for to get more community involvement. Centralization would encourage involvement? How? Do they need to get a shell account on the linux from scratch server machine and log in there to do their development? I don't understand... Rob -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
