unstable branch for LFS

zigman2k zigman at gmx.net
Tue Oct 15 13:39:15 PDT 2002

isn't this discussion about stable/unstable book started because of the major
gcc and glibc updates (especially the glibc part)... and how often are those
"incompatible versions to previus versions" releases (like gcc-3.3 and glibc-2.3)?
once every year or so ?
and btw.... correct me if i'm wrong... but the reason that gcc-3.3 doesn't compile
ncurses and man isn't because gcc isn't stable.. its because the ncruses and man
sources are kinda broken and need to be fixed...
what i am saying is that maybe a "glibc-2.2.5 to glibc-2.3.1 update hint". and just 
go on and use the new stuff in cvs

*********** REPLY SEPARATOR  ***********

On 15.10.2002 at 14:10 Gerard Beekmans wrote:

>On October 15, 2002 06:15 am, Matthias Benkmann wrote:
>I'm about 300 lfs-dev emails behind, so i'll try to catch up asap. This
>it was due to Thanksgiving. Me and my wife decided to go out to the lovely 
>mountains for a bit. I come back, hords of email.
>Okay....unstable book. Yes sounds good, yes I want it, yes long time ago
>probalby nobody but me remembers I once wanted to do it but due to time 
>constraints we decided not to do it yet. That's not an issue anymore
>I haven't read all the replies to this thread, but one I did read was that
>might be hard for us the editors to maintain two seperate books. Since if
>make a change to the stable book we should make that same change to the 
>unstable book to keep them in sync right? That way an unstable book can be 
>released a stable book later down the road easily since all the stable
>elements are already present. This ideally is done without us making the
>update twice in two directories.
>So I propose this: we can use one and the same XML tree to house both the 
>unstable and stable books. Anybody remember me talking about dynamically 
>render a customized lfs-book by switching some XML tags that add/remove 
>certain pages/chunks from the book?
>Similarly we can easily add "unstable" XML sections that are only visible
>you enable an entity. If disabled (by default) a normal stable book is 
>To me that sounds like the easiest solution. But then there's CVS - it'll
>be a 
>tad harder to keep track of the changes and revert back to older chagnes
>you have to figure out which commits were updates to stable or unstable 
>branches. Having a seperate unstable branch has quite a bit of good points 
>when it comes to revision history and all the likes and will increase our 
>workload a bit. Just one branch that does it all, but smart usage of XML 
>techniques, will make it easier for us (editors) but a bit harder for 
>administrative purposes. Now the latter most people don't care about,
>for the editors themselves. I'll think this through more thoroughly and
>a definite answer soon. In the mean while feel free to come up with your
>ideas how this can work nicely.
>Gerard Beekmans
>-*- If Linux doesn't have the solution, you have the wrong problem -*-
>Unsubscribe: send email to listar at linuxfromscratch.org
>and put 'unsubscribe lfs-dev' in the subject header of the message

Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list