About the future format for LFS (reworded)

Ken Moffat ken at linuxfromscratch.org
Mon Sep 1 16:59:56 PDT 2008

On Mon, Sep 01, 2008 at 05:39:39PM -0400, William Immendorf wrote:
> Ken Moffat wrote:
> > So far, I've managed without java, and I see absolutely zero reason
> > to install it on my machines.
> Unforuntaly, we have to put Java as a reqirment here for the validator (JNVDL) and the transformer. (Saxon) You will have to live with that.

 Last time I looked (admittedly a _long_ time ago), java didn't build
on the architecture I was using, with the then-current toolchain.
No, it wasn't x86, but at the moment I can happily render my local
versions which sit on a different architecture.  You haven't yet
understood that _you_ have to persuade _us_ of the merits of the
change, not tell us we'll have to live with it.  The last thing LFS
needs is greater barriers to involvement - using a whole additional
toolset had better provide some tangible benefits.

> > At the moment, you haven't bothered to reply to my questions and
> >comments.  I have noted that the dynamic book will be able to provide
> >different package managers for different users, but I'm still in the
> >"I came here because I loathe the overhead of package managers" camp.
> I just don't know how to reply to form posts. Just can you tell me?

 Huh ?  AFAIK I sent a standard reply to this list, in the same way
as my mail to which you have just replied.

> Also, for the package managament, nobody is about to push you off a cliff and say "USE PACKAGE MANAGEMENT NOW OR ELSE!!!". You have the freedom of choice to use package management or not.
> >Who the hell are you to say "this is the way forward" without
> >providing argued reasons ?  (Valid answers might include "Gerard's
> >nominee", or perhaps you have some existing position in the LFS
> >projects of which I'm unaware.)  If you merely intend to _propose_ a
> >change, you _have_to_ provide better justification for it.
> This started in a March 2008 post titled "Format for the future of LFS". It has been disscused through the years and I decided to start it back up again.

 OK, so in March there was the discussion which eventually went
quiet, and now you are _proposing_ a solution based on that.  But
don't you see that your choice of language is almost guaranteed to
put people's backs up ?
> >What changes does it mean for individual editors?
> They have to write some generic non PM and arch-independit files (yes I was thinking of merging CLFS into LFS), and then write PM-spefic instructions, and some archspecif instructions.

 Three comments on that:

1. Obviously, I wasn't clear - what changes to my *workflow* and
*tools* ?  At the moment, I have the docbook tools on my server.  I
make an edit, then run the Makefile.  The main tools in that seem to
be xmllint and xsltproc, which have a fairly light list of
dependencies.  Now, I will apparently need java - what else ?

2. Specifically, if I want to locally render all the variations of a
book to check that my editing makes sense, what extra tools would I
need ?  You sound as if apache and php will be required for this ?
Maybe even an SQL database ?  If so, this is far more software than
my fileserver is scoped for.  For comparison, in clfs I can make a
specific version of the book, or make them all, just by selecting a
different target in the Makefile and waiting for it to run.

 At the moment, I have no idea how the dynamically-generated book is
supposed to work.  For example, suppose we have a selection of boot
loaders in the book.  Some combinations are clearly invalid, but of
the others I might want to render all the available combinations of
architectures and boot loaders to make sure that my latest textual
correction reads properly everywhere (and that it changes all the
places - I've seen discrepancies creep in to clfs).

3. I know that Jeremy's branch attempts (or should that be
'attempted' ?) to cover ppc and x86_64, but there is far more than
that in clfs, particularly multilib (that was generally agreed in
the earlier discussions to be a step too far for LFS at the moment),
other architectures, and the sysroot and embedded books.  You might
wish to consider trying to persuade the clfs editors of the merits
of this proposal - the biggest problems in both projects are lack of
manpower including people to test it,  forking the book does nothing
to help that.

> >So, how does that help ?  When I've made edits, I've never felt the
> >need for an element that isn't available.  Certainly, I often think
> >there are too many elements, but that is because some of the people
> >here care more deeply than I do about some of the nuances of how the
> >book is rendered - so, the elements I think are not particularly
> >important are indeed useful and ought to be retained.
> We don't have to remove elements, I just wanted to give a example.

 But, you haven't yet given any examples that make me think "that's
a good idea".
> >You refer to the "tired old screen and userinput combo" - where is
> >the problem with it ?  Maybe you are caught up in the "web 2.0"
> >buzzphrases ?
> It is not a buzzphraze, both screen and userinput are elements, BUT, I can't write 'em in tags because it won't come out properly. We could write a code element that can replase both.
 You are (deliberately ?) misunderstanding.  I know full well that
tags run foul of the spam filter.  I use the screen...userinput
combination like all the other editors do.  AFAIK, no-one has ever
said that there is a problem in doing that.  This just sounds like
change for the sake of it.

 In a subsequent post you mentioned keeping apache, some sort of SQL
database, and php up to date - for a secure server.  Taking LFS and
BLFS together for this, we are not good at finding quick fixes for
new vulnerabilities (we're not organised like a distro, we aren't on
vendor-security, so at best we lag the other distros by a few days
and at worst we can go months before noticing).  I can't speak for
anyone with the ability to upgrade software on the LFS server, but
this sounds to me like fertile ground for the bad guys.

das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-dev mailing list