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
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
