unstable branch for LFS
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
>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.
>-*- 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