Ysgrifennodd kevin@seti-inst.edu ar Sul, Maw 21, 1999 am 10:53:17PM +0000: > No. If a program *needs* to be compiled in order to work with the new > libraries, then the new libraries are not truly compatible with the > old libraries, and the libraries need a new soname. I didn't say that programs had to be recompiled. I said that some programs have not been modified to do things 'correctly'. For example, ISTR that the reason libtricks doesn't work is that it uses internal symbols that are not guarenteed to be exported. Programs like that should be expected to break - that's why most people don't use (or shouldn't use) internal symbols. I was not aware that other programs, eg glib and elm, would break. If it is indeed glibc's fault that these programs don't work, then I would say that the glibc maintainers were wrong not to increase the soname. However, we have to first find why these programs don't work - we cannot simply blame it on glibc. I had assumed that the glibc maintainers were suitably experienced with this kind of coding that they would have changed the soname, if the library was incompatible. If, in fact, they have made a mistake, they should be informed of that, and it should be corrected. I notice also that the glibc maintainer does not seem to think it needs a new soname. Since there is disagreement about this, perhaps someone/some people should look at what is involved, and decide what is the correct approach. Talking in the abstract will not cause a solution to appear. > When a user upgrades to a new release of Debian, working programs > should not break. Programs should not require recompilation. Our > upgrade from libc5 to libc6 was fairly smooth because we had separate > soname. I have heard it said that glibc2.0 and glibc2.1 cannot coexist. If this is correct, then it will not be possible to do this in the same way. > Our job is to decide whether we need a new soname, then strongly > encourage other Linux vendors to support our decision. We shouldn't > make a bad decision just to join the crowd. > > Of course, if libc2.1 can be fixed, we don't need to worry about this > issue. It depends whether glibc2.1 is broken in the first place. I have heard arguements either way, and I fear that there will never be a complete agreement on this. If glibc can be s/fixed/modified to work with glibc2.0 compiled programs, then I think this should be done, as long as it doesn't affect glibc in other ways. Alternatively, we could modify the programs that don't work, and cause the new versions to conflict with glibc (<=whatever) (do we have versioned conflicts? Maybe that's something that is needed). This would force those users concerned to upgrade to glibc2.1, but I do not see that as a problem. Diolch, Edward.
Attachment:
pgpJz9ElVJnxd.pgp
Description: PGP signature