On Sun, May 05, 2002 at 10:58:11AM +1000, Brian May wrote: > On Sun, 2002-05-05 at 10:38, Jeroen Dekkers wrote: > > Am I right that you actually want to have libeditline provide > > libreadline, but a simple Provide: won't work here because versioned > > provides don't work? > > Hmmmm... Interesting point. > > If libeditline conflicts, provides libreadline, and has > /usr/lib/libreadline.so*, then it would be 100% ABI compatible, and > programs would be able to use either. (you could argue that it isn't > currently 100% ABI compatible due to the different name). Names doesn't have much to do with the ABI, it's a way to find the library, the dynamic linker won't find it if it has some random name. > Just some issues you might encounter though: > * package depends (For non-GPL packages) need to prefer > libeditline over libreadline (my understanding only). That's true, but the user could choose to use libreadline instead of libeditline. > * version provides won't help; the version numbers are > completely different. No, because if versioned provide would work, you could say: Provide: libreadline4 (== <version it is compatible with>) > * All programs would have to use libeditline if installed, even > those that are capable of using libreadline. This might be > good for some people, not so good for others. The user could choose to use libreadline instead of libeditline if it wants to without violating the GPL. If needed, maybe we could do some dynamic linking magic to have both libraries exist at the same time. This actually started me thinking about what http://master.debian.org/~brinkmd/arch-handling.txt says, especially the last example about glibc ABI. I think the way libraries are handled in Debian can be done better, it should be more focused on the actual ABI of the library than the version number of the package the library is in. In this case, you would probably want the following: libreadline4 package: Provide: libreadline.so.4 libeditline0 package: Provide: libreadline.so.4 Random package using readline: Depend: libreadline.so.4 It gets tricky when new functions get added, this doesn't break the ABI but will break the compatibility between the libraries. I think this is best solved by depending on libreadline.so.4.2 if the new function is added in version 4.2. The best thing would be if all libraries use versioned symbols, but AFAIK only glibc does that at the moment. I'm probably overlooking much more problems here, but I think the idea is at least nice. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: jeroen@openprojects
Attachment:
pgpcTuQVdOUrG.pgp
Description: PGP signature