Re: libsilc package policy violations (bug #273871)

[Jeff Carr <jcarr@linuxmachines.com>]

Steve Langasek wrote:

> > 4) the package itself is not the right name
>
> 4) is an approximation, but not actually a correct description (it's the
> same incorrect approximation used by Policy itself).  The problem is that
> the package name is not being changed when the library soname changes, which
> means that silc's shlibs are completely useless for preventing breakage of
> packages depending on it.

OK.

> This is not a theoretical; I recall that when this bug was being discussed
> on IRC a week or so ago, there were cases of actual packages whose
> dependencies were satisfied but required a previous silc soname and were
> therefore completely broken.

OK. That's interesting. I wonder if the problem in this case is with the 
upstream sources.

> There is no reason to require any *particular* package name for a library,
> except that it should be unique; basing it on the soname is the best way to
> ensure that it's unique in a future-proofed manner.  The following command
> gives the policy-recommended package name for any library:

OK, thanks for the further enlightenment. I'm afraid I'm still being 
dense however. If I may, here are some other SONAME files from some 
other libraries in sid.

objdump -p /usr/lib/libsilc-1.0.so.2.1.0 |grep SONAME
  SONAME      libsilc-1.0.so.2

objdump -p /usr/lib/libgnomeui-2.so.0.800.1 |grep SONAME
  SONAME      libgnomeui-2.so.0
objdump -p /usr/lib/libgnomeprint-2-2.so.0.1.0 |grep SONAME
  SONAME      libgnomeprint-2-2.so.0
objdump -p /usr/lib/libgnomecups-1.0.so.1.0.0 |grep SONAME
  SONAME      libgnomecups-1.0.so.1

To finally get understand this problem correctly then, is it that the 
libsilc-1.0.so.2.1.0 library was the SAME name as a previous version 
with an identical but incompatable SONAME? So, the problem with this 
package is that the debian/rules file does not correctly increment the 
SONAME for incompatable library releases?

So, the SONAME in this latest release of the libsilc package should have 
been something like "libsilc-1.0.so.2.1" or "libsilc-1.0.so.3" instead 
of "libsilc-1.0.so.2" so that other packages could correctly list the 
right version as a dependancy?

I looked around in debian/* for this package trying to figure out how it 
might be fixed. Now it seems to me that the problem is more how the last 
few versions have been packaged & versioned, not that this particular 
version is packaged incorrectly or needs to be changed. So what really 
needs to happen is future versions need to change the versions in a 
correct fashion if they are not binary compatible?

Thanks for your explianation on this; as it's not clear to me. I'd like 
to know the correct method of doing things here. Does it sound like I 
almost understand it right now?

Jeff