libc6 posix version/breakage
What led to this email is the fact that coreutils built under the
current libc6 exhibits behavior that breaks a *lot* of stuff in debian.
For example: head -number and tail -number don't work anymore, so
dpkg-buildpackage fails. Apparantly other gnu tools will exhibit the
same sort of changes as soon as someone rebuilds them against the
current unstable libc. One possibility is to change the reported posix
version in /usr/include/unistd.h. The downside to that is that it masks
the problem from a user perspective, but at least it would give us some
time to fix breakage in the debian packages. The right answer is to
probably plan a transition on debian-devel. Thoughts?
----- Forwarded message from Paul Eggert <eggert@CS.UCLA.EDU> -----
X-Original-To: mstone@mathom.us
To: Jim Meyering <jim@meyering.net>
Cc: Michael Stone <mstone@debian.org>
Subject: Re: [Coreutils-announce] coreutils-5.0.90 released
From: Paul Eggert <eggert@CS.UCLA.EDU>
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Several weeks ago an anesthesiologist walked up to me at a dinner
party and complained that his GNU/Linux box was giving him weird
diagnostics on his scripts. It turned out Gentoo libc switched to the
new POSIX version, which caused coreutils to default to the new
behavior. (Don't you just love 10-year-old POSIX time bombs? They
make for fun dinner-party conversation. :-)
> What I will probably have to do is change anything that's disabled in
> that case to succeed and print a "deprecated" message unless
> POSIXLY_CORRECT is defined. Any thoughts?
It's not just coreutils; other packages look at _POSIX2_VERSION.
(diffutils springs to mind, but I'll bet there are others.)
How about this much-simpler workaround instead: patch glibc so that
_POSIX2_VERSION has its old value. That is more honest, since you
probably still have some programs that don't conform to POSIX
1003.1-2001 yet. _POSIX2_VERSION is supposed to say what standard
your utilities conform to; glibc doesn't really know what the proper
value for that is, so you can fix its guess with a light heart.
This simpler workaround will give you some time to fix the rest of
Debian. Debian developers like yourself should set
_POSIX2_VERSION=200112 in their environments, and let the bugs get
found and squashed.
You can remove the glibc patch in a few months (or years), after the
dust has settled somewhat.
Someone needs to file bugs against the offending packages.
Here's a tiny start. I'm sure there's a lot more
I've been filing bugs as I encounter them. E.g., Debian bugs 191669,
203292, 204361, 204372.
Here's the script that I use to find potential problems. I call this
command 'grep-nonposix'. I can send you the output of it on a Debian
testing host, if you like. (I don't use Debian unstable; Jim's braver
than I am.) Or I can file bug reports from the output, if you'd
prefer that.
#! /bin/sh
LC_ALL=C
export LC_ALL
IFS='
'
pattern='(expand|head|fold|split|tail|uniq|unexpand|nice|diff)\>.*[ ]-[a-zA-Z]*[0-9]|(sort|tail|uniq)\>.*[ ]\+[0-9]+[a-zA-Z_]*|sort\>.*[ ]-o'
case $1 in
--help)
exec echo "$0: usage: $0 [OPTION]... [FILE]...
Grep for instances of possible POSIX-conformance problems in the FILEs.
Options:
-s Check strictly, even for things that aren't likely to be real problems.
The FILEs can be directories, in which case the greps are recursive,
though ChangeLogs, backup files, and version-control histories are bypassed.
The default FILE is '-', which stands for the standard input.";;
-s)
pattern=$pattern'|[ef]grep\>|(\[|test\>).*[ ]-[ao]\>'
shift;;
esac
pattern='\<('$pattern')'
case $# in
0) exec grep -E -n "$pattern";;
*) exec grep -E -n "$pattern" \
$(find "${@-.}" -type f \
! -name '*~' ! -name 'ChangeLog*' ! -name '*,v' \
-print \
| sort);;
esac
----- End forwarded message -----
Reply to: