On 07/13/2011 03:26 PM, Bruce Dubbs wrote:
> 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
...
> 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.
I'd much rather see /bin, /sbin, and /lib move _out_ of the top level,
but of course nobody would seriously consider doing that and having all
the non-volatile OS files be collected under one directory...
>>>> 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?
Sorry, I agree with Linus Torvalds' assement of SVN's motto ("CVS done
right") from his Google Tech Talk, and thus tend to mentally collapse
the two together when I'm not paying attention. But yes, I meant 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.
So the message to people new the project is they have two choices:
1) Try the latest known-good release, which produces a system roughly on
par with Ubuntu 8.04 "hardy heron" (desktop version end of lifed May
2011), or SuSE 11 (end of lifed June 2010).
2) Your first experience with BLFS can be attempting to build a nightly
source control snapshot. You may get to be the first person EVER to try
this particular combination. Which apparently has some fundamental
reason for not having been turned into a stable release in forever.
While making this decision, ponder: was 2008 the last time the
developers _bothered_ to cut a release, or the last time developers
_managed_ to cut a release? Are they lazy, or overwhelmed by their own
project, or do they simply not care about giving outsiders a known good
version?
And you wonder why the flow of new users/developers into the project has
tailed off? Releases are _important_.
>>> 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.
So does Mercurial. It's distributed source control.
> 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.
You'd remove this giant roadblock if anybody used the road.
> I acknowledge that some would think it a chicken/egg problem, but it
> wasn't when we first started BLFS.
When you first started BLFS the only interesting target was 32-bit x86,
single processor. (I type this on a 64-bit 4-way netbook that retails
for $248 at Target, plus a $23 memory upgrade.)
Back then, XFree86 was the only viable X11 option. The Linux source
control system was "periodic tarballs with changelogs". Supporting
video and 3D wasn't an option. Dialup modems were by far the most
common way to access the internet, and the largest ISP was AOL.
We're discussing package upgrades because the world moved on.
>>>> 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).
And exists right now in the one big book. Gnome is chapter 29 of the
book, how many of the previous chapters do you need to install first?
Even in the _relevant_ chapters, like 8, do you need libusb? How about
libpthread-stubs?
Chapter 10 has xterm, which requires the X libraries from chapter 23.
Chapter 10 also has Xscreensaver which presumably also requires them,
but doesn't say so...
There are large chunks where you can say "if you don't want servers, you
can ignore section V, it might as well be a different book". "If you
don't want Gnome," "If you dont' want KDE", "If you don't want X11".
"I'm not going to connect this machine to a network." (why chapter 4 on
security isn't in the networking section, I don't know...)
What's _left_ that you can't easily ignore should either be a base BLFS
book or folded into LFS itself as an extra section at the end.
> To suggest multiple books, we need to look at a proposal with what
> packages go in each book.
That was my first post to this thread.
> That would be quite challenging and I'm sure
> generate a lot of discussion.
Not so far.
>> 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.
I was pretty much taking the chapters that were already there and
sorting them into obvious groups, initially at the chapter level.
(There are a lot of roman numeral sections providing faultlines already.)
But if you'd like to try to start over from scratch...
>> 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.
Great. Why not cut a release?
> -- Bruce
Rob
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
