# 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 Windows. > > 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 forever.
Attachment:
signature.asc
Description: This is a digitally signed message part