[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libreadline

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

>         * 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: pgpcHiFThyITe.pgp
Description: PGP signature

Reply to: