[gnutls-dev] gnutls versioning again

[Dmitry V. Levin]

Hi,

On Sun, Feb 18, 2007 at 05:56:30PM +0100, Andreas Metzler wrote:
> On 2007-02-15 Dmitry V. Levin wrote:
[...]
> > To resolve this issue, our gnutls package maintainer had to create new
> > interface, e.g. GNUTLS_1_6_1 and place new symbols there.  As result,
> > every package with software which uses these symbols will automatically
> > have all necessary dependencies, e.g. libgnutls.so.13(GNUTLS_1_6_1),
> > so any user installing this package will also update gnutls package.
[...]
> Your proposed change would not improve things for Debian at all.
> The current way for searching dependencies in Debian is
> symbol-versioning agnostic
[...]
> Afaict things are different for rpm.  /usr/lib/rpm/find-provides and
> /usr/lib/rpm/find-requires seem to handle versioned symbols, but will
> never generate a normal versioned dependency. rpm looks into "Version
> References" and "Version definitions" in opbdump's output and handles
> libgnutls.so.13(GNUTLS_1_3) instead of just libgnutls.so.13. Therefore
> you end up with stuff with --requires
> 
> libgnutls.so.13
> libgnutls.so.13(GNUTLS_1_3)
> 
> and the gnutls library package --provides
> 
> libgnutls.so.13
> libgnutls.so.13(GNUTLS_1_3)
> 
> So afaict Dmitry's change might indeed improve things for rpm.

Yes, it does.

> However
> it seems to be a rather big hammer. And the problem is old, I think I
> am missing something _big_, the majority of libraries does
> not use symbol versioning,

Probably because symbol versioning is not portable.
Most of libraries which use symbol versioning are maintained by
GNU/Linux developers.

> rpm based distributions must already have
> some different way to handle adding of symbols to libraries and
> generating the necessary dependencies.

Besides of the the method we are talking about, there are no reliable
methods I'm aware of.  rpm based distributions usually follow reactive
strategy: when application package fails to run with some library
package, they just rebuild application package with verioned dependency on
library package which is known to work nice with this application package.

I prefer (and introduce in Sisyphus) a proactive solution instead.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20070218/a8494f08/attachment.pgp