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

Re: libsilc package policy violations (bug #273871)

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.


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?


Reply to: