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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
