[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#227386: libc6-dev: ENOTSUP==EOPNOTSUPP, which violates SUSv3

# bcc'd to control
forwarded 227386 http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363
thanks, control, and have a nice day

On Sun, 2006-02-19 at 17:36 +0100, Aurelien Jarno wrote:
> severity 227386 minor
> thanks

I'm not going to play bug tennis with you.  I think the bug should be
rated important because it breaks code and even if it didn't, it
violates the standard.  Standards are there to ensure interoperability,
so that software authors are not required to implement workarounds for
every broken OS on the planet.  If I wanted to deal with a lack of
standards and implement workarounds all the time, I would program for

> > I agree that the problem is trivial, but it's still a bug, and it
> > bites me frequently.  I am a little disappointed that a bug that
> > is probably quite trivial to fix has been open for over two
> > years.
> Because it is not so trivial?

The bug is trivial to fix.  However, because of decisions to keep the
same SONAME for glibc, it will take creativity and imagination to fix,
since there is no point at which compatibility can be broken.  This in
itself is a bug, but I really don't care since I don't have to deal with
it.  If the glibc maintainers want to make it hard on themselves by
having to support breakage for eternity, that's fine, as long as they
support non-breakage too.

I would like to point out that AFAIK none of the native libcs of
FreeBSD, NetBSD, or OpenBSD have perpetual SONAMES, and therefore can
fix problems at some (possibly undefined) point in the future.

I will note that a defect report has been filed and accepted (with
changes) by the Austin Group as XBD Enhancement Request #54.  However,
it is only a note to the editors for future revisions.  Therefore, until
such time as it is accepted into the standard, glibc is broken.

> > So, here are some solutions, as I see them (in order of my
> > preference):
> > 0. glibc fixes the error codes so that they are different
> > (I prefer this because GNU/kFreeBSD has the same problem,
> > unfortunately).
>  > 1. Linux fixes the error codes so that they are different.
> Doing either 0 or 1 will break binary compatibility, which means that:
> 1) All packages potentially using ENOTSUP or EOPNOTSUPP have to be 
> rebuilt. This is unacceptable.

glibc cannot claim compatibility with POSIX 1003.1-2004 by defining
_POSIX_VERSION to 200112L unless it fixes this or the standard changes.
It would be a lie to claim that glibc supports a standard which it does
not in fact support.

Anyway, it would significantly reduce the number of packages to be
recompiled if the new error number were only used if _POSIX_SOURCE is
defined to 200112L.

> 2) Debian will loose binary compatibility with other distributions, 
> unless they do the same. We do not want that.

IIRC, we already did with OpenSSL.  The social contract states that our
priorities are *our* users and free software.  It makes no mention of
Redhat's or Slackware's or anyone else's users.  Personally, if one does
not recompile when moving from distribution to distribution, there is no
guarantee of even the most basic functionality anyway.

> In short, Debian can't take the decision itself, please see with the 
> upstream of glibc.

Filed as stated above.

> > 3. I work around the bug by adding logic to check if they
> > are the same and print a big fat warning telling people
> > that GNU/Linux is buggered and encouraging people to use
> > an OS that cares about POSIX compatibility.
> I wonder to know which OS will you advise. FYI, all *BSD systems are 
> also using the same value for both ENOTSUP and EOPNOTSUPP.

I know.  That would also qualify them as broken.  However, I may just
recommend "an OS that cares about POSIX compatibility".  IOW, I need not
specify an actual, specific OS, just criteria.

> > Right now, it looks like if either 0 or 1 don't happen by
> > 18:00 UTC on Monday, that I will do option 2 (falling back
> > to option 3 as stated).
> I don't like ultimatums, so please go for one of the options 2 to 4.

It wasn't an ultimatum, simply a statement of fact.  Generally, an
ultimatum takes the form "p or q" (where q is generally very
unpleasant).  I said, "if p, then q"; the two are not logically
equivalent.  I won't wait forever to commit my code, nor will I commit
broken code.  I am willing to wait and hope for a short time, but not

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: