Glibc configure options in unstable

Jeremy Utley jeremy at jutley.org
Fri Sep 10 06:41:26 PDT 2004


On Fri, 10 Sep 2004 14:32:53 +0100 (BST)
Kev Buckley <k.buckley at lancaster.ac.uk> wrote:

> 
> > This has been mentioned before, but in the unstable branch of the
> > book, 
> > the text is not being actively kept in line with the commands. 
> > Unstable 
> > is meant to be a playground, and as such, may be broken at any time
> > as 
> > we experiment.  We try to keep breakage down to a minimum, but it
> > does 
> > occur.  
> 
> I think the answer that is being looked for here is to the question:
> do you always break it in the same way though ?
> 
> To put that another way, should one trust the commands, or the text,
> where the differ, when playing with a given unstable version ?
> 
> I would guess the commands but it would be just a guess.
> 
> Presumably, as with much of software development, you type some
> commands and, if they are found to work, you add those to the unstable
> book and you "document" later, no ? 

Exactly.  When development is working properly, the commands are worked
out in the Unstable branch of LFS, and the documentation would be added
in when those commands migrate into testing.  There are sometimes cases
where something may actually end up in testing first, such as a patch,
or a new package upgrade, but these are the exceptions.  So, to answer
your question, in a given Unstable book, the commands will be what we
are actively testing on, even when the text is out of sync.

What may eventually happen is that the text will for the most part be
stripped from Unstable, leaving only the commands.  Unstable is meant
for those who are already experienced, those who can and will monitor
the development lists (-dev and -hackers) to learn about the new things
that are happening.

HTH,

-J-



More information about the lfs-dev mailing list