About the future format for LFS (reworded)

[William Immendorf]

Ken Moffat wrote:

>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.

If you can't install Java, no ploblem. You can always look at it online, only that you can't generate it.

>Huh ?  AFAIK I sent a standard reply to this list, in the same way
>as my mail to which you have just replied.
>http://linuxfromscratch.org/pipermail/lfs-dev/2008-August/061569.html

I use web based mail, and I can't do it with that.

>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 ?

I just wanted to bring it back up again. The idea sounds great.

>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 ?

Only to build the book. You can still edit it, only you will need Java to build.

>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.

How 'bout we do it, clfs style. That will work and we don't need PHP, apache, and *SQL for that.

>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).

Well, the book and the tarballs will still be autobuilt from svn automaticaly. But the XML source from scratch? No way.

>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.

Combinding the teams togher will extend the LFS team greatly, and we can have one LFS for an arch and a package management type.

>But, you haven't yet given any examples that make me think "that's
>a good idea".

Whoops, I forgot. But it will help get rid of clutter.

>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.
 
JH's dLFS test (at http://lightcubesolutions.com/~jhuntwork/dLFS/) uses a code element, why not use that for LFS instead of the screen and userinput combo. That wil probaly work well.

>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.

Never mind the *SQL and the PHP part. We won't have to worry about updating them.
_________________________________________________________________
Talk to your Yahoo! Friends via Windows Live Messenger.  Find out how.
http://www.windowslive.com/explore/messenger?ocid=TXT_TAGLM_WL_messenger_yahoo_082008