On Nov 8, 2011, at 1:17 PM, Bruce Dubbs wrote:
> In the last three weeks, I have updated about 64 packages in BLFS. I
> started to look ahead. This is where we stand:
Bruce,
What you've been doing lately has been commendable, and your effort amazing.
I'm sad that you've come to what appears be an impasse. Further comments
inline.
> LFS 7.0 checked: 64
> LFS 6.7 checked: 97
> LFS 6.5 checked: 143
>
> There are, in addition, somewhere around 320 packages that have no
> annotation. That is a total of about 625 packages.
>
> Another statistic is that the pdf version of BLFS as 1481 pages.
>
> I will continue to update, but I'll probably slow down as what I've
> already done has a lot of relatively simple packages (and a few
> not-so-simple ones).
>
> What has been obvious for some time is that we cannot produce a BLFS-x.x
> release. First, there are not enough developers with the time needed to
> do the necessary work. Second, and probably more important, is that
> with the number of packages in the book, the change rate is just too
> great to produce such a book in what could be called a timely manner.
Before proceeding further, I'd like to understand the nature of the effort you
just put into BLFS. I see the development of BLFS as a somewhat different
activity from LFS, despite the fact that both use the same medium of DocBook.
I would guess that become of dependencies (or lack thereof) LFS is a roughly
linear effort, whereas BLFS (with its philosophy of supporting each package in
both standalone- and used-along-with-package-X-modes) is a combinatoric effort
(not to mention the innate combinatoric complexity of managing references).
It would seem to me that BLFS, then, exposes this combinatoric complexity
mainly in the book.
So, I'm wondering: "Is editing the book; i.e., keeping the SGML DocBook
up-to-date, the main time sink of developing BLFS?"
* * *
IMO, LFS has two products: a working system, and the book--which serves as
documentation and an educational resource. This working system is as important
a product as the book. But, because the effort to develop and maintain the LFS
book is roughly linear (yes, this is my assumption/inference), it doesn't get
bogged down by itself. In addition, I don't walk away after following the LFS
instructions with the feeling that I have to tinker. While that feeling is
obviously personal and subjective, the after-taste of going through an LFS
build is that it's "solid". That I "don't have to tinker." And, instead,
that: "I'd rather not tinker, because it's known to work."
BLFS also has two products: working packages and the book. But, in the case of
BLFS, the book seems to be the main source of the effort (likely due to the
nature of the complexity of supporting so many packages). It seems clear that
only when someone wants to build "Package A" using "Package X" as support does
the book need to require a paragraph of description and a code segment to
describe how to build A with X. My point is, it takes someone who actually
cares about "A with X" to require its inclusion; so, the process of testing "A
with X" already has a human resource behind it. In addition, that person could
probably produce a README or a MediaWiki entry (just some stabs at
alternatives). I would imagine, then, that the issue with BLFS is that to
finalize the inclusion of "A with X"--into the BOOK--requires writing SGML,
maintaining the references, blah blah blah, and that starts to require much
much more manpower.
So, in constrast, with BLFS perennially in the "non-release" state, it *always*
feels like tinkering. And, that doesn't seem right. LFS--and by extension
BLFS could be a very usable Linux system that doesn't make people feel like
they are "tinkering". While I realize certain people have legitimate security
concerns, I don't see how they are any worse than with common distros and the
ways that casual admins use them. A "release" of some subset BLFS makes it
clear that it works with some version of LFS, and quells the feeling that
something needs "tinkering" at a very low level. Even though how one
configures a package is dependent on the capabilities compiled into a package,
I don't want to worry that my package was compiled incorrectly and will cause
my app to fail, or that some strange set of dependencies which was at some
random revision in SVN--is going to introduce subtle errors into my
application. That is the purpose of a release.
Now, my assumptions are mainly based around this point--that BLFS has
combinatoric complexity, and that the book captures--and thus requires--the
effort to resolve those complexities. If this assumption is false, then my
later assertions are equally false...
> I am proposing to send out the following announcement:
>
> ---------
>
> BLFS is announcing a new release methodology. The book will not be
> released as 'stable' or 'development', but will be produced in an
> ongoing release cycle. The book will be entitled "Beyond Linux From
> Scratch - Version yyyy-mm-dd". New versions of the book are rendered
> daily, but the version dates are only changed as content is updated.
>
> Most package build instructions in the book will be annotated "This
> package is known to build and work properly using an LFS-x.x platform."
> This will give users an indication about when the package was last
> updated. In most cases, older instructions will work with little or no
> modification on more recent versions of packages used in the book.
>
> ----------
I think BLFS is two things:
1) a set of instructions that creates a set of working packages on top
of LFS,
and
2) a book which pretty-prints all this information.
At this point, is it worth questioning why BLFS must be maintained as both that
set of instructions (implicitly, as someone probably has to test this stuff
before it goes into the book, right?) as well as an SGML DocBook? Because a
set of instructions is likely to be manageable. But not so manageable when it
has to be massaged into an SGML DocBook. If the instructions themselves are a
product that is manageable--and thus release-able regularly--then I would argue
that the bulk of the effort ought to be directed at keeping those instructions
up-to-date and released on a regular schedule (say, in line with LFS, which I
thought was sort of the end-goal of your recent efforts) and less at the
DocBook.
I mean, if you can isolate a version of BLFS (e.g., your "BLFS - Version
yyyy-mm-dd") and you can say: "It works with LFS-x.y", then aren't you at that
point cutting a release already? What else could a release of BLFS be, other
than to say: "The stuff we've identified works with LFS version
such-and-such."...? To the extent that it's anything more than that, you'd
need some sort of testing to get from "released" into "verified" territory, and
that's a new can of worms...But, let's at least admit there's a difference
between: "Yes, this will be compiled right if you use these instructions," vs
"Well, this will *likely* be compiled right, but you won't know until you see
some weird issue."
Compiling the packages yourself seems to be a major component of the
attractiveness of LFS and BLFS. But, if these -FSes are to be anything of
value, isn't it to ensure that the compilation process is correct? So,
furthermore, if LFS can do it--and keep an SGML DocBook up-to-date--that's
awesome. But, if BLFS can do it--but CANNOT manage to scare up the resources
to keep a similar book up-to-date...Who cares? I mean, if you're a tinkerer,
you already don't care what state a given product is in. You have the time &
inclination to DIY. If you simply want to use a system, particularly if that
system is in a "live" setting, would you prefer a set of instructions that
compiles correctly with a given LFS version? Or a set of compilation
instructions that you have to piece together--and get forum support with? The
point is--if you're someone who doesn't care what state BLFS is in (maybe
because you like to tinker), then stick to your message--and don't care. I
think there's
value to having a "stable" BLFS (with the criteria that any stable version
compiles correctly with a given LFS version).
================================================================
TL;DR - I think the SGML DocBook maintenance is what's causing the complexity
to be too high to be release-able in a timely manner. I also think the book
contents--if divorced from their presentation concerns in DocBook--are useful
without the book formatting.
The instructions themselves, the meat--the content, very important. Their
presentation, less so. So, put the work into the instructions. And maybe spin
the book itself off to some other group who cares that it's in SGML DocBook
format. Not that I am suggesting using Word, but quite frankly, even if it
*was* a Word doc, I couldn't care less. Yes, I recognize that if BLFS became a
flat text file, keeping *that* up-to-date will become its own annoying chore
over time. But, this is 2011-almost-2012, and I think the smart people here
could probably figure something out other than SGML DocBook. How about even
just maintaining a MediaWiki implementation? Sure, you would lose all the SGML
compiler verification...But, frankly...how important is that? See the next
quote--
> In addition I can update the web site to reflect this change. There
> would be no regular pdf or nochunks versions of the book, but a tarball
> of the current book's html will be available.
The point is, if there's not going to be a PDF or nochunks released, but just a
tarball of the current HTML, why not simply forget about the presentation, and
focus instead on maintaining the instructions for building the system? I mean,
isn't this statement, all on it's own, already suggesting that maintaining the
SGML DocBook is too hard?
So, my question is: "Is maintaining the SGML DocBook the most significant
burden that fights against the stability--and release-ability--of BLFS as a
USABLE SET OF WORKING PACKAGES on top of LFS?"
In addition, for those who want to move in a "verified" direction (as in, "this
works how it's supposed to without crazy surprises, and we've outlined the
perimeter such that outside of those conditions, the system might not work" vs
"this compiles correctly")...How about starting to consider the idea of
"unit-testing" whole systems (or their subsets)? On one hand, getting around
to building something as complex as PHP (let's say with database and imaging
support) and running the PHP unit tests is already testing huge parts of the
system. OTOH, a PHP unit test that breaks doesn't really tell you whether it's
a bug in PHP, or if it was somewhere deep in how you compiled glibc. I would
think that creating system testing (I'm not sure what precedents are out there)
is a better use of time than SGML editing. Of course, testing will require
effort and manpower, too, but I'm throwing this bone out there to address some
obvious follow-up questions about the relative value of BLF
S "releases".
================================================================
Q
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
