thomasp at linuxfromscratch.org
Tue Jan 13 19:27:59 PST 2004
On Tue, 2004-01-13 at 21:59, Kevin P. Fleming wrote:
> 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?
I'll admit that I don't fully understand all this POSIX compliance
stuff, but what you suggest sounds good to me.
LFS User : 4729
Linux User : 298329
More information about the alfs-discuss