Subject: Re: Shared library dependencies revisited

From: [email-masked] (Bruce Perens)
Date: Mon, 12 Aug 96 11:42 PDT

Ian,

We can make your proposal simpler by using virtual package names to
find the libraries.

Each package that provides a shared library should, for each shared
library that it provides, automaticaly add something like
"Provides: libX11.so.6" to the control file. Each package that depends
on a library should automaticaly add "Depends: libX11.so.6" to the
control file.

If you want to know about the executable format, you could prepend
"elf-i386-" to the library name.

	Thanks

	Bruce

---

From: Ian Jackson <[email-masked]>
Date: Tue, 13 Aug 96 14:26 BST

Bruce Perens writes ("Re:  Shared library dependencies revisited"):
...
> find the libraries.    [ eg Provides: libX11.so.6 ]

This is a very interesting idea, thanks for the suggestion.

As it stands there are a couple of problems:

Firstly, we need to depend on a particular version of the package, so
that the library version number is high enough for ld.so not to
complain.  If we use virtual packages we need to implement virtual
package versions in dpkg, which is (a) a big job and (b) hard to
deploy (because it's a change to the syntax of the Packages file).

Secondly, some packages (the X11 libraries package is a good example)
contain many different shared libraries.  It seems silly to include a
dependency on each one.  For example, xbase depends on 7 different X
libraries, all part of the xlib package, and many packages depend on
both libc and libm, which come together.  If we do as you suggest
these packages will have long and confusing dependencies.

Further suggestions welcome.

Ian.

-chiark:~> ldd /usr/bin/X11/xterm
        libXaw.so.6 => /usr/X11R6/lib/libXaw.so.6.0
        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6.0
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6.0
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6.0
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6.0
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6.0
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6.0
        libncurses.so.3.0 => /lib/libncurses.so.3.0
        libc.so.5 => /lib/libc.so.5.2.18
-chiark:~> ldd /usr/bin/a2p 
        libgdbm.so.1 => /usr/lib/libgdbm.so.1.7.3
        libdb.so.1 => /usr/lib/libdb.so.1.85.2
        libdl.so.1 => /lib/libdl.so.1.7.14
        libm.so.5 => /lib/libm.so.5.0.5
        libc.so.5 => /lib/libc.so.5.2.18
-chiark:~>

---

From: [email-masked] (Bruce Perens)
Date: Tue, 13 Aug 96 15:52 PDT

> find the libraries.    [ eg Provides: libX11.so.6 ]

From: Ian Jackson <[email-masked]>
> [...] we need to depend on a particular version of the package
> [...] some packages contain many different shared libraries.

OK. Have each library-provider automaticaly include a "Provides: " for
each library that it provides, with the name indicating the
architecture, executable format, soname, and major and _minor_ numbers
of the library.

The tool that looks for library dependencies in packages finds 
the packages that provide virtual package names matching the libraries
it needs, and adds a dependency for the _actual_ package and its version
rather than for the virtual package name.

This is still overloading "Provides:" for half the process. If you don't
like that, you can put it in another field ("Exports:"?). This still allows
you to leverage on the existing database rather than to add another file
to the package. 

	Thanks

	Bruce
--
       Clinton isn't perfect, but I like him a lot more than Dole.
            Please register to vote, and vote for Democrats.
Bruce Perens AB6YM          [email-masked]            http://www.hams.com/

---

From: Ian Jackson <[email-masked]>
Date: Wed, 14 Aug 96 04:11 BST

> rather than for the virtual package name.

But we need to know the least recent version which will satisfy a
dependency based on this library, which depends on library minor
numbering.  This information would have to be there too.

> you to leverage on the existing database rather than to add another file

You're right, I don't like reusing Provides for that purpose.

I don't see that another field is much different to another file in
dpkg's status area - the question really becomes one of database
optimisation.  dpkg already has mechanisms for handling files
DEBIAN/<spong>, filing them in /var/lib/dpkg/info, and removing them
with the package.

But, you have convinced me that DEBIAN/<spong> is the right place for
this file.

(Not putting it in the control file makes it easier for the shared
library package maintainer to put what they want in it, now that
package control files are very auto-generated.)

So, all that remains, I think, is to specify the syntax of the file:

How about
 <library-name> <soname> <dependencies-in-dpkg-syntax>
eg
 libc 5         libc5 (>=5.2.18-2)
or
 libc 4         libc | libc4
or some such.

If we put the package name there then we can have
/etc/dpkg/shlib.defaults with default values for when the library
package doesn't have the file (for transition &c) and
/etc/dpkg/shlib.overrides for overriding them.

I'm almost convinced now that this is the right thing to do.

Schemes involving Provides and so forth provide very little
flexibility about what gets put into the dependencies of the package
which uses the library.  This way the package providing the library
can specify what the dependencies should look like.

Ian.