Version in glibc
zach at kotlarek.com
Thu Nov 13 02:19:28 PST 2008
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2746 bytes
Desc: not available
More information about the lfs-dev