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. http://linuxfromscratch.org/pipermail/lfs-dev/2008-August/061569.html > 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. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
