On Tue, 2006-02-21 at 16:22 +0100, Aurelien Jarno wrote: > Brian M. Carlson a écrit : > > 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? I don't know how many packages were in hamm, because the earliest I ever used Debian was slink or potato. The website doesn't tell me either. I can tell you that now we have 15490 packages, according to Debian's front page. IIRC, we had a little over 8000 with woody. > > 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. Indeed, that is true. > > > > 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. I could believe your argument if it were decided *before* Linux and BSD, but if they did it *after*, they would have to know about the differences. > > 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. Debian is supposed to be a universal operating system. We have ports to non-Linux kernels (the Hurd, kFreeBSD, and kNetBSD). Should they comply with the LSB, too? If not, to what standard should they comply? > > 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! If a program requests POSIX compatibility, then it can only expect POSIX compatibility. My program expects only what the POSIX standard allows, and it allows (and requires) those two errors to be different. > > 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. That's true, we don't forbid them to do so, but neither do we require that they do so. I'm having trouble finding it now, but someone filed an RC bug on either libc5, libc6, or one of the libstdc++ libraries, and complained that the Oracle installation they were using no longer worked. IIRC, the bug was marked wontfix. > 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. The LSB is only for Linux. You (as a developer for GNU/kFreeBSD) should know that Linux is not the only kernel out there. Therefore, it would make more sense to support SUSv3 instead. And anyway, if we were really gung ho about the LSB, we would ditch the .deb format and switch to the LSB packaging format (a stripped down version of RPM). Additionally, I think the LSB is stupid and does nothing to help Free Software, because it will encourage vendors to write binary-only software (without source), which, when it breaks, will be useless. Also, unless we maintain compatibility with every old LSB version, such code will break sometime, and will most likely never be fixed[0]. Furthermore, I claim that my priority is not only those users that use Debian exclusively, but also those users who develop on Debian and expect their code to work on a different system, or those who develop on other systems as well as Debian. Additionally, I claim as a priority the users even of our non-Linux ports. > By introducing a new define, you are breaking standard compliance. Well, there is no better way. You want to preserve binary compatibility at the expense of all else. I want to preserve standards compliance at the expense of all else. I am trying to offer a compromise. > > 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. > > 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. Actually, no it won't. It will continue to return the "wrong" value (EOPNOTSUPP) that existing code returns. At some point, one might want to fix that with new @GLIBC_2.3.7 symbols, but I'm not going to implement that right now. Also, see the paragraph above. > 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. Because my code is not broken at this time. I live by the old saying, "If it ain't broke, don't fix it." > 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. If and when that happens, my code will be broken, and I will be happy to fix it. Expecting that I act as if something will happen, when I cannot be certain it will, is silly. It's the same as if Debian required that all Debian package conform to LSB 4.0. In summary, my complaint is that glibc claims conformance when it is not actually conformant[1]. Therefore, I want one of the following things to happen: * glibc becomes conformant with standards it advertises. * glibc no longer advertises standards with which it is not conformant. [0] Vendors are still shipping modern Ethernet cards with Linux drivers from 2.0 or 2.2. Doom binaries from Id Software require *libc4*. What makes you think that any vendor will support a reasonably recent version of the LSB? [1] If you are going to claim conformance, please fix kill(2) as well. If you are planning to do that, but need a bug to remind you, I'll be happy to file it. Otherwise, I won't bother.
Attachment:
signature.asc
Description: This is a digitally signed message part