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
smime.p7s
Description: S/MIME cryptographic signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
