Thanks for a very nice, thoughtful post. Rob Landley wrote:
>> 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? Yes, there is actually some discussion about it. FHS has been discussing an update on their list: https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss The /run directory will almost certainly get into the next version. The issue of merging /usr into / has been discussed a bit, but I don't think it is seriously being considered. There are a couple of points: a separate /usr is not supported by systemd. Personally, I think that's a problem with systemd, not the FHS, however, we have to keep in mind why /usr was separate in the first place. In the early days of Unix, disk space was quite expensive. Today it's cheap. Only a very few system have /usr as a separate partition, let alone as a network mount. Today, I think the rationale for a separate /usr is for file organization. Not having a /usr directory would promote directories like /share, /include, /src, /local to the top level. IMO, limiting a major directory to less than 20 subdirectories is useful. >>> We don't exploit the branching model. If we were to move to >>> Git where branching is cheap and merging is easier, things could get >>> done a lot quicker. > > Having the whole of BSD or KDE in a single source control tree leads to > scalability issues. Branching is not a substitute for having a modular > system where packages have prerequisites. > > Yay replacing CVS. People keep telling me "LFS issue X is fixed in CVS" > and I wait for the next release because I only look at CVS when paid to > do so. But I'm not sure that's BLFS's problem. CVS? Do you mean svn? BLFS does create a daily build, so looking at the -dev version is no more difficult than the release version. It's been a long time since the -dev version of BLFS was seriously broken. It's biggest problem today is that most packages are out of date. It's still quite useful though. >>> 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. > >> 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. Bazaar also offers that. I'm not sure I'm ready to move to bzr or git though. I'm probably just set in my way too much though. If there was a bit more activity asking for that, I might change my mind. I acknowledge that some would think it a chicken/egg problem, but it wasn't when we first started BLFS. >>> The reason why CBLFS >>> seems to be easier is that it has less information to worry about, > > Hence breaking it down into smaller books that depend on each other in a > modular fashion. > > All of it's going to depend on the base LFS, so this is nothing new. > >>> Splitting the BOOK up into smaller books, e.g. X11, Gnome, Kde, might >>> sound good, but I feel that this would have it's own problems. As an >>> example, having a separate Gnome book, would GTK go into this book? > > Nope, gtk is independently useful for things like xfce or standalone > "x11 boots straight into an app" kiosk systems. The Gnome book would > depend on the gtk book as a prerequisite. How many books? If you have a book like BLFS-base, are all packages in BLFS-base required before BLFS-gnome? The problem of dependencies is quite complex (and circular). To suggest multiple books, we need to look at a proposal with what packages go in each book. That would be quite challenging and I'm sure generate a lot of discussion. > A set of books to extend LFS to full LSB system could make sense. Hmm: LSB Core: Bc, Cpio, Ed, Fcrontab, PAM, Sendmail (or Postfix or Exim) and some not in the book now (at, init_tools). LSB Desktop: ATK, Cairo, Desktop-file-utils, Freetype, Fontconfig, Glib2, GTK+2, Icon-naming-utils, Libjpeg, Libpng, Libxml2, MesaLib, Pango, Qt3, Qt4, Xorg (All in BLFS now ) LSB Runtime Languages: Python LSB Multimeda: Alsa Libraries, NSPR, NSS, OpenSSL, Java LSB Printing: CUPS This info is already in the LFS preface. > The thing is, Ubuntu has a team of full-time employees who maintain a > repository. Last time I checked, the debian repository had 43,000 > packages in it. Competing with distros isn't really very interesting. Yes, but it's actually quite surprising how few packages are needed by most people that are not in BLFS. That set varies of course by each person. For most people who have built LFS/BLFS, it's generally pretty easy to build most of those. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
