Bug#227386: libc6-dev: ENOTSUP==EOPNOTSUPP, which violates SUSv3
Brian M. Carlson a écrit :
On Mon, 2006-02-20 at 07:51 +0100, Aurelien Jarno wrote:
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.
Attached.
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.
It's been done at least once before. However, if there were a libc7,
Could please give me the number of packages affected and compare to now?
then all packages need not be rebuilt right away, because conceivably
libc7 would provide /lib/ld.so and libc6 could use that. However, I am
not necessarily advocating that, just pointing out that it is not
impossible. The only thing is that packages could not use both libc6
and libc7, directly or indirectly.
Which means that they almost all have to be rebuilt.
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.
As I said above, attached.
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!
That does not mean we should not fix it. You are claiming that
"everyone does it".
Everyone does it because they have no other choice. POSIX standard has
been decided after the design of the Linux kernel and of the BSD ones,
so it is not compatible with the current design.
That's why Linux does not claim POSIX compliance, but only "aims towards
POSIX and Single UNIX Specification compliance".
> If everyone jumps off a bridge, should Debian do
> that, too?
If Debian follow the SUSv3 standard instead of the LSB as you suggest,
that would be like jumping off a tower. Debian has chosen.
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.
I would argue that such programs expect non-standard behavior while
asking only for standard-conformant behavior. They are buggy.
So you are changing the behaviour of the glibc, and then you qualify as
buggy programs that have a valid source code. Hahaha!
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.
I wasn't aware that we gave any support whatsoever for third party
software, hence the term "third party". Packages from non-free that are
provided only in binary form would have to be removed (or recompiled by
upstream) if there were a security problem.
Debian does not provide such support, but as "our priorities are our
users and free software", we don't forbid them to run such programs.
The errno numbers have been like that for years, ie since 1991 for Linux
(and even more long for *BSD), and they are *standardized* in the LSB.
Everybody plays happily with that, but you prefer to come and break
binary compatibility, saying that we should support SUSv3 instead. Then
you can't claim that your priority are the users.
Looks like the upstream have the same opinion...
And I have done what Ulrich asked: filed a bug on the Linux kernel.
However, please do not reassign this bug to linux-2.6 because the Debian
kernel maintainers will close it, apparently not realizing that Linux,
as well as glibc, has a certain responsibility for standards compliance.
What my patch does is use the value of _STRICT_POSIX to modify the value
of ENOTSUP. As more ABI incompatible changes occur that cannot be fixed
any other way, this value is bumped, keeping the old code still there.
So the valid values of _STRICT_POSIX are as follows:
0, or undefined: same old and broken behavior that has always occured.
1: change ENOTSUP to a valid value
99999: use the largest supported value for _STRICT_POSIX
any other positive integral value: set _STRICT_POSIX to 1 and warn
Personally, I would recommend making getconf return
-D_STRICT_POSIX=99999 where applicable, but I understand that some
people might use getconf and not depend on strictly-conforming POSIX
behavior, even though such a use is incorrect.
By introducing a new define, you are breaking standard compliance.
It is my belief that this meets the binary compatibility criteria: the
code only breaks compatibility if someone explicitly requests it, so if
someone unintentionally breaks their code, they did it themselves.
Additionally, if glibc is built with the new error code, strerror and
friends will support it, but they will also support the old code, since
it is the same as EOPNOTSUPP. I have not, however, tried to compile
with the patch; it is untested.
Due to binary compatibility reasons, it is not possible to make the
functions that return ENOTSUP on Linux return the new error code unless
new versions of those functions are implemented. For the same reason, I
have modified Linux-specific code to use EOPNOTSUPP and code that is
used on, but not specific to, Linux check for __linux__ and ENOTSUP !=
EOPNOTSUPP and return EOPNOTSUPP instead.
Please note that this patch only works for Linux, but does not change
the behavior (or errno values) of non-Linux platforms.
I agree that your patch solve your problem, ie it allows two different
value for EOPNOTSUPP and for ENOTSUP. But programs that use this
functionality won't work, as the glibc will return ENOTSUP while they
will check for EOPNOTSUPP. That's not acceptable.
Why you don't fix your code instead of creating more problems than you
try to solve? You say us you already have a technical solution in your
code for EWOULDBLOCK and EAGAIN. Please apply the same for ENOTSUP and
EOPNOTSUPP.
If you don't do it now, you will have to do it later, as SUSv3 will
probably be modified to the allow same values for both EOPNOTSUPP and
ENOTSUP, as requested by the LSB.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: