Bruce Perens writes ("Re: Shared library dependencies revisited"):
...
> 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.
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.
> 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.
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.
