Howdy, all.
"Long time user, first-time poster."
I've used [a-z]LFS in a HPC research environment. Now I'm considering using it
to deploy a Xen cluster (which is a great marriage of the "slimness" of LFS,
the idea of virtualization, and the new Xen support in the mainline kernel).
(I have some comments on the "The State of BLFS", and while I seem to coming in
on the middle of this discussion, I think my message is pertinent to the intent
of this thread's subject. I hope you'll find it appropriate.)
LFS itself is easy to follow, because it's so "autocratic"; i.e., there is ONE
set of instructions, and that one set is complete authoritative. Even though
it may not be explicit, the tone of much of the LFS-support mailing list is
that if you are a relative-novice and you don't follow the book, then the most
likely solution to your problem is: FBBG.
BLFS is clearly awesome, especially in scope. You folks who put this together
are doing an amazing job at a VERY difficult job. What makes BLFS so much
harder--and have such a different "flavor", IMO--from LFS is the simple fact
that most people are going to pick-and-choose. If we take a "complexity"
approach to evaluating the difference, LFS has roughly linear complexity with
the number of packages. But, BLFS has combinatorial complexity (and this isn't
even getting into the nightmare of optional dependencies).
Now, obviously, BLFS is "behind" LFS (at least in keeping up-to-date with LFS
and the packages themselves in BLFS). The combinatorial complexity means that
BLFS can't even be manageably crowd-sourced (even if everyone is contributing
in a well-behaved way to the book). I'd like to consider a "functional"
approach. Instead of focusing on a "core" BLFS (that seems to be just
advocating pushing packages into LFS...), perhaps there could be different
maintainers of "cross-sections". Once you get out of pure LFS, a lot of the
package decisions will be based on how you intend to deploy it, and each "use
case" defines a "cross-sections", or a "path".
For some folks, it seems like X is a big focus. But, for instance, my use of
[B]LFS is purely headless. What about creating "functional paths" like:
"Desktop", "Headless Server", "Dev Server"? These are just suggestions, of
course; there would likely be others, perhaps even at different granularities
("LAMP Server" vs "Firewall/Network Dark" vs "LAPP" vs
"node.js/V8/coffeescript/RoR", etc).
In that example, I could see the Desktop "path" including X, Gnome, KDE, Sound,
Video, etc. The production server path wouldn't include compilation tools, but
would include different production-related server packages (tcpwrappers, NTP,
tcpdump, sudo, and your app-server/web-server/RDBMS of choice). The Dev Server
could follow the various language tools, mail servers, source control, user
management (e.g., quotas), etc.
It doesn't matter if there's package overlap; i.e., if the same package (say,
tcp-wrappers) is in multiple paths; it's simply a matter of keeping each path
"current" and "autocratic", to allow people to follow it easily. Maintainers
of the paths could simply use this list to say: "Hey--I want to integrate
package X into my path. Does anyone have some tips about pitfalls to avoid?
I'm already using configure options L, M, and N, and wondered if there might be
anything to watch out for." I'm, of course, making the assumption maintainers
would have to do that anyway, in the existing BLFS. It seemed like a safe
assumption...
* * *
TL;DR - One book is likely too great a burden for a single point of
maintenance, because of the combinatorial complexity that BLFS suffers from
(which doesn't affect LFS). In that spirit, "paths" could be created in BLFS
for different uses. This has the benefit of reducing the "cost of
support"--directly support only each "path", and "off-roaders" would have to
resort to asking around in BLFS-support for help (which is probably likely in
the current state anyway). Secondly, it has the benefit of directly
incentivizing certain folks to be maintainers (they'd work on the path they
want/need). For instance, I'd be interested in working on a XEN path and/or a
LAPP path (in case anyone was starting to wonder if I'd not just squawk, but
contribute). ;) It seems like a simple way to start. Choose two variants (I
think the "Desktop" vs "Server" paths are probably good candidates) and see if
it's possible to maintain separate, overlapping books, all under the umbrella
of BLFS-x
(where 'x' is just the path). The umbrella serves to unify the maintainers,
so they know the community they should communicate with, and it still allows
"off-roaders" to go to BLFS-support for questions; they just have to know that
they may not get the response they were looking for. Folks taking the "path
well travelled" would probably get their answers faster, or at least be told to
RTFM, as happens in the LFS-support thread.
* * *
Regards,
Q
On Jul 30, 2011, at 5:23 AM, Wayne Blaszczyk wrote:
> On 30/07/11 21:20, Thomas Trepl wrote:
>> On Saturday 30 July 2011 02:29:55 Randy McMurchy wrote:
>>> ...
>>> I was hoping that my response to your post would encourage additional
>>> responses. Actually, I am surprised that it has not. All that has
>>> happened is additional packages have been added to the book which is
>>> the opposite of where you suggest we go. I am wide open. Let everyone's
>>> opinions flow!
>>>
>>> I am open to suggestions, let the community speak out! C'mon, we need
>>> to keep BLFS alive!
>>
>> Oh yes, the topic should cause an agile discussion. I think to come up with
>> valuable suggestions is nearly as hard as keeping BLFS up to date ;-)
>> However,
>> some interesting ideas, opinions and suggestions did came up and to me -
>> speaking for myself - it looks like the following:
>>
>> I hardly think that BLFS reaches a level of complex which is not longer
>> maintainable but in my eyes, the quality standard has grown that high, that
>> it
>> makes a simple version upgrade or add a new package to a remarkable time
>> consuming task. Maybe we cut that a bit - for example, the depenencies of
>> packages is where we should do a review. As I said in another post, it isnt
>> quite clear when is what required, recommended or optional.
> I thought i mentioned my opinion on this quite some time ago, but here
> it is again?
> I think we should keep the recommend dependency.
> Recommend should be a dependency that is no required to build the
> package successfully but requires a disable parameter if it is not
> installed otherwise it fails.
> Optional should be a dependency that is no required to build the package
> successfully and does not require a disable parameter if it is not
> installed for a successful build.
> This is a black and white rule that should not have any ambiguity.
> Anyone have any objection by this definition?
>
> A package needed
>> because the other package will not compile if it is missing - this package
>> is
>> of course required. But the difference between 'recommended' and 'optional'
>> is
>> not clear (to me) and maybe can merged in one section.
>>
>> Another thing where I'm thinking about is the topic 'Release'. To me there
>> are
>> only two options:
>>
>> Either do releases, which will result in some kind of "stable book"s which
>> can be seen as something that really works fine, but maybe does not use the
>> most recent versions. The development branch will be freed from the trammel
>> of
>> 'it all must work with eachother'. This is the devel-branch and bugs, errors
>> and incompatibilities are allowed to happen. As I'll say later again, that
>> may
>> speedup development and makes it easier to have new versions in the book.
>> But
>> the challenge will be to come to a state wher a stable release could be cut
>> off.
> This is what I was trying to convey, having multiple branches where
> things aren't so perfect.
>
>>
>> Or, the other option, if we will not cut releases, then drop the stable
>> book
>> as it is a (3 years old) *release*. Than rename "Development BLFS" into
>> simply
>> "Beyond LFS book" or so. But when doing so, we also need to drop the demand
>> on
>> 'everything works perfect with each other'. Than I think, it will not be
>> possible to check all the time if pkgconfig will still work when upgrading
>> glib2 from 2.24.2 to 2.24.3 (ok ok, I know, thats a dumb example). But what
>> I
>> want to say is that we should go a bit more in the direction to assume that
>> other pkgs will still work if upgrading. If not, someone will recognize and
>> report that and then this could be fixed.
> For the most part that would work, but as an example, if you upgraded
> glib2 which broke Gnome, then the only option would be to upgrade
> Gnome's 50+ packages which would take ages to do so. We might end up in
> a never ending cycle of catch up.
> That is why I say something like Gnome should have a separate
> development branch.
> A separate branch is just like having a separate book but with some
> benefits.
>
> Working on such a ticket is a team
>> issue where it can be discussed how to fix, do this, do that. If you want
>> upgrade a pkg, currently you are more or less alone to find and fix
>> incompatibilities (before you commit an upgrade). Maybe relaxing here could
>> help to speedup in the race with new package versions. Thats a different
>> approach as we must tell the people that we do our best to keep everything
>> working, but when it does not, ok, we have warned you that this could happen
>> but will try to fixed that.
>>
>> You see, I like the 'bleeding edge' thinking - everything is quite uptodate,
>> but because of that, it may not work proper. So be it ;-) But what IMHO
>> will
>> not work is to live at the bleeding edge AND keep it stable.
>>
>> I still didn't come to a decision on whether I like or not the idea of
>> splitting the book in more (more or less independent) parts. But I feel
>> thats
>> an idea which is worth to think about. What I would not like so much is to
>> transform the book into a wiki. I believe that there will be too much
>> efforts
>> to keep it structured which is automatically done using the docbook.
>> Learning
>> the latter is not that hard.
>> That does not address Fenna's idea of doing a full restart and keep what we
>> have in a wiki (or whatever). The idea of doing a restart from scratch is
>> cool
>> as it may offer the option to modify the docbook stuff for whatever
>> improvements instead of need to update hundrets of XMLs. Another effect
>> could
>> be that we could see, where people are really interested in.
>>
>> Just another 2 cents,
>>
>> --
>> Thomas
>
> --
> http://linuxfromscratch.org/mailman/listinfo/blfs-dev
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
