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 <[EMAIL PROTECTED]> -----
X-Original-To: [EMAIL PROTECTED] To: Jim Meyering <[EMAIL PROTECTED]> Cc: Michael Stone <[EMAIL PROTECTED]> Subject: Re: [Coreutils-announce] coreutils-5.0.90 released From: Paul Eggert <[EMAIL PROTECTED]> 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 "[EMAIL PROTECTED]" -type f \
! -name '*~' ! -name 'ChangeLog*' ! -name '*,v' \
-print \
| sort);;
esac----- End forwarded message -----
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
