About the future format for LFS (reworded)
ken at linuxfromscratch.org
Mon Sep 1 13:48:16 PDT 2008
On Mon, Sep 01, 2008 at 01:57:10PM -0400, William Immendorf wrote:
> Bruce Dubbs wrote:
> >> the biggest
> >> barrier I think we have, is the fact that xmllint and xsltproc couldn't
> >> handle RNG documents correctly.
> >To me this is a show stopper. We need those or the equivalent programs to
> >generate the book in its various forms, wget-list, etc.
> Then try both Saxon and Sun MSV (Multi-Schema XML Validator). However, they need Java, so be preapred for that.
So far, I've managed without java, and I see absolutely zero reason
to install it on my machines.
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.
That still leaves the majority of my post unanswered. To paraphrase
(bearing in mind that I mostly ignored the noise about package
management and dynamic books earlier this year, waiting for something
that was in a fit state to comment on):
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.
What changes does it mean for individual editors ?
Why is adding packages such as php to the LFS webserver (when we
appear to be extremely slow to update for known vulnerabilities) a
good idea ?
> >> After spending all this effort, just to get us to the same state as we're in
> >> currently (i.e. can validate and render the book sources), what, definitively
> >> do we gain?
> >I asked this question yesterday too. Until that is answered satisfactorily, I
> >don't think the current build method will be changed. As of right now, I just
> >don't see any significant benefit, but a lot of effort.
> The advantage is that we can create elements that we want. Rember, XML is eXtendible. Like a code element that replases the tired old screen and userinput combo.
> We can also remove useless elements.
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.
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"
At the moment, I don't have a killfile. People _discussing_ the
development of the book have a right to be heard, even if I dislike
what they say. But you apparently come out of nowhere with a
statement of "Что делать"(1) and no explanations of why you think
this will improve anything. You are trying my patience.
1. - the original title, in Russian of "What Is To Be Done ?" by
Lenin - at least according to wikipedia - I've dropped the question
mark because you aren't asking, you are proclaiming.
das eine Mal als Tragödie, das andere Mal als Farce
More information about the lfs-dev