About the future format for LFS (reworded)
computerperson1 at live.com
Mon Sep 1 18:25:52 PDT 2008
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.
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.
More information about the lfs-dev