Bug#227386: libc6-dev: ENOTSUP==EOPNOTSUPP, which violates SUSv3
Brian M. Carlson a écrit :
# 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.
The problem is not that there is currently not possibility to fix the
bug without broking everything, at least nobody found one. Please
provide us a patch instead of complaning.
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.
We can't change the SONAME for the glibc because it is plainly
impossible to rebuild all packages. Have you look how difficult was the
latest c++ transition? It could qualified as very very simple comparing
to a glibc transition.
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.
Again if you are not happy with the current situation, stop complaining
and provide us a patch.
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.
Those systems have choosen not to use packages, and everything is
rebuilt at each new version. That's and advantage, but some users also
like having a packaging system.
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.
Which is the case for almost every systems. AFAIK, every have a small
part which is not POSIX compliant. You've just found one for GNU/Linux!
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.
That only ensure code compatibility, but will still break binary
compatibility because the new glibc will use the new numbers, while
binaries that have not been rebuilt will use the old one.
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.
Loosing binary compatibility means that users won't be able to use third
party software, or packages from non-free that are provided in binary
form. But as you said "priorities are *our* users and free software", so
we could not do that. Also note that software provided in binary form is
usually compiled in static but the glibc, so the OpenSSL do not break
third party software.
In short, Debian can't take the decision itself, please see with the
upstream of glibc.
Filed as stated above.
Looks like the upstream have the same opinion...
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: