On Wed, Apr 20, 2005 at 01:40:14PM -0700, Jeff Carr wrote: > Robert McQueen wrote: > >Tamas SZERB wrote: > >>once upon a time, I closed this bug. then the submitter reopened it, > >>so currently I don't give it a f*ck. Our opinion are different, so if > >>you feel any ambition to get the both sides together, feel free to > >>volunteer. :) > >This package's violation of Debian policy on the packaging of shared > >library packages is a fact, not an opinion. You have given no sound > >reasons why this package is not correctly versioned, or given any > >indication that you understand the issues at hand, such as how it is > >expected to retain compatibility with existing packages when the API or > >ABI undergoes changes (indeed, as it has just done upstream). > Could you help explain to me more clearly what the problem is with this > package against debian 8.1 guidelines? After reading the bug report at > bugs.debian.org It's still not clear to me how the package should be > changed. It seems quite subtle. I tried comparing it to some of the > libgnome* packages to see if I could determine what was correct, but it > still wasn't clear to me. > Which one is a correct description of the problem? > 1) the libsilc package should not contain /usr/lib/libsilc.so at all > 2) the /usr/lib/libsilc* symlinks are not correct > (wrong names or missing needed names) > 3) /usr/lib/libsilcclient-1.0.so.2.1.0 is not the right name > 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. 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: $ objdump -p /tmp/silc/usr/lib/libsilc-1.0.so.2 \ | sed -n -e's/^[[:space:]]*SONAME[[:space:]]*//p' \ | sed -e's/\([0-9]\)\.so\./\1-/; s/\.so\.//' libsilc-1.0-2 $ -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature