Glibc-2.3.3 tarball

Kevin P. Fleming kpfleming at
Tue Jan 13 18:59:25 PST 2004

Greg Schafer wrote:

> The main problem with this approach of automated fixage is that you're not
> fixing the problems at the core. i.e. the upstream packages need to be fixed
> eventually so someone needs to be sending patches upstream.

Thomas and Jamie, if you haven't been following this discussion on 
lfs-dev, it relates to the pending upgrade of the LFS book to glibc 
2.3.3 (or higher), and the effects that has on coreutils-5.0 
(specifically, it causes the head/tail utitilies to complain about 
non-POSIX-200? compliant usage).

I think when this change goes into LFS, we should make the applying of 
the coreutils-5.0 patch optional (but included by default). In addition, 
we can wrap the <make> commands for packages with scripts known to 
generate the POSIX compliance errors with a <stage> setting 
_POSIX2_VERSION to the correct value so that head/tail don't complain. 
This way, the profile is buildable whether you apply the coreutils patch 
or not, and when each offending package gets "fixed", the explicit 
setting of _POSIX2_VERSION in that package's profile can be removed.

Thoughts? Opinions? Is this too radical a departure from the book?

More information about the alfs-discuss mailing list