Version in glibc

[Zachary Kotlarek]

On Nov 13, 2008, at 12:44 AM, TheOldFellow wrote:

> Following this logic, we should document:
>
> #define VERSION "2.8-20080929-LFS-svn20081101-built-by-John-Doe"
>
> since we can't control how it was really built.  It's for this reason,
> lack of control of the build options, that we MUST not call LFS a
> distro. (You'll say Gentoo isn't one either then, and I agree)



And following that logic RedHat should include a glibc validation  
script that dynamically updates the version string in case some user  
applies a binary patch to the library.

Yes, we can't control what end users do. Neither can distros. That  
doesn't seem to stop them from adding their own versioning  
information. We may not want to follow that model, but the fact that  
users can do something different than we decree isn't a strong argument.

--

That being said, I don't think adding the LFS string is a good idea.  
Given the already -- let's say "undiplomatic" -- view that upstream  
has of any mere mortal attempting to build glibc I think LFS-specific  
version strings would just be used as a further excuse to ignore bug  
reports or support requests. Even more understanding folk could easily  
read it to mean "glibc + some LFS-specific patch" unless they were  
familiar with LFS.

While there is some additional information provided by adding an LFS  
tag it would take quite a bit more to actually nail down a specific  
set of build instructions -- something fairly long like the commit  
number or date plus the book version -- and even then it would only be  
useful to people familiar with LFS. It's not useless information, but  
I don't think the potential utility of the extra information is worth  
the potential for extra hassle.

	Zach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2746 bytes
Desc: not available
Url : http://linuxfromscratch.org/pipermail/lfs-dev/attachments/20081113/6207b899/attachment.bin