I have been getting this error on my package for a long time:
E: planner binary: duplicate-entry-in-shlibs-control-file libmrp
The tree view shows:
/usr/lib/planner/
|-- file-modules
| |-- libmrp-xml.so
| `-- libmrp-xsl.so
|-- libgantt-task.so
|-- plugins
| |-- libhtml-plugin.so
| |-- libmsp-plugin.so
| |-- libpython-plugin.so
| |-- libsql-plugin.so
| `-- libxmlplanner-plugin.so
|-- storage-modules
| |-- libstorage-mrproject-1.so
| `-- libstorage-sql.so
`-- views
|-- libgantt-view.so
|-- libresource-view.so
|-- libtask-view.so
`-- libtimetable-view.so
Based on this, I'm wondering if the error might actually be
caused by Lintian's inability to process SO libraries with a
dash in the filename and a similar first half in the filename?
- -- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (990, 'testing'), (1, 'unstable')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.17-imac
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Versions of packages lintian depends on:
ii binutils 2.17-2 The GNU assembler, linker and bina
ii diffstat 1.43-1 produces graph of changes introduc
ii dpkg-dev 1.13.22 package building tools for Debian
ii file 4.17-2 Determines file type using "magic"
ii gettext 0.14.6-1 GNU Internationalization utilities
ii intltool-debian 0.35.0+20060710 Help i18n of RFC822 compliant conf
ii libparse-debianchangelog 1.0-1 parse Debian changelogs and output
ii man-db 2.4.3-3 The on-line manual pager
ii perl [libdigest-md5-perl 5.8.8-6.1 Larry Wall's Practical Extraction
lintian recommends no packages.
- -- no debconf information
iD8DBQFE7U2ZeXr56x4Muc0RAn7BAJ4qTRM0y8aIPS6qsvj1PMFu7RaU3gCeNsJm
nvoGFX9i8yfKifVsIHVMyHM=
=kRSe
-----END PGP SIGNATURE-----
Martin-Éric Racine <q-funk@iki.fi> writes:
[...]
This error isn't about the files stored in your package; rather, it's
about the shlibs control file in your package. The contents of the file
are:
libplanner-1 0 planner
libmrp xml planner
libmrp xsl planner
libhtml plugin planner
libmsp plugin planner
libpython plugin planner
libsql plugin planner
libxmlplanner plugin planner
libstorage-mrproject 1 planner
libstorage sql planner
which certainly does look broken. Since those binaries are in a
subdirectory of /usr/lib and are not public libraries or (apparently) used
outside this package, it seems to me that they shouldn't be listed in the
shlibs file of the package at all. Anyway, per Policy 8.6.3, that shlibs
file is really not in a valid format; the second field is supposed to be
the SONAME version number. And it does indeed contain a duplicate entry.
Policy isn't particularly clear on the requirements for the shlibs file
for plugins that are only used internally by that package, but my
understanding is that there's no reason to list them. I'd be inclined to
add -X options to dh_makeshlibs (which there should be some mechanism to
do via CDBS) to ignore those plugin directories, or possibly even argue
that CDBS should be doing this automatically.
I'd be curious to hear other opinions on this, though. I may be missing
something.
On Thu, August 24, 2006 19:24, Russ Allbery said: Yes, indeed. parsed as meaning that anything following the first dash in the filename should end up as the second field of the shlibs file. That is generated by dh_makeshlibs from debhelper. Could this be where this parsing bug is? [...] Valid point. I might indeed simply exclude them.
As discussed in the bug log, the shlibs file really is invalid, so lintian's behavior here is correct. I'm not sure if dh_makeshlibs is doing the right thing or not in this case; it is intentionally parsing SONAMEs in that way, and there's a comment in the source that seems to indicate this is done because of an annoying SONAME syntax used in some packages. I'll leave it to you whether you want to just exclude these files from dh_makeshlibs or open another bug against debhelper to see if its matching logic can be improved.
reopen 384424 reassign 384424 debhelper thanks pe, 2006-11-10 kello 21:18 -0800, Debian Bug Tracking System kirjoitti: Since the issue itself is not resolved, reassigning this bug to debhelper makes more sense than closing it. Doing this now.
Hello Joey, I notice that you never got around replying to this issue. Has any progress taken place? Cheers!
Martin-Éric Racine wrote: No; the problem is that there actually are libraries that have a soname of "$library-$major.so", and there is no real way to differentiate this from your plugin's SONAME. (If bug #205142 were fixed, then dh_makeshlibs would avoid looking in subdirectories of /usr/lib, and so skip the plugins that way.)
Hi, I recently run into a similar porblem of badly formated sonames causing a broken (incomplete in my case) shlibs file. Both dh_makeshlibs and dpkg-shlibdeps use the same patterns to extract the name and version from SONAME: <name>.so.<ver> <name>-<ver>.so As said in the bugreport already it is impossible to differentiate reliably between <name-with-dash>.so and <name>-<ver>.so. It is also impossible to handle <name>.so in shlibs. So even if it could be detected it would be impossible to generate an shlibs entry for it in the current format. The solution to the poblem comes with symbols files. The symbols files for planner could contain (guessing what the actual SONAME is): libplanner-1.so.0 planner libmrp-xml.so planner libmrp-xsl.so planner libhtml-plugin.so planner libmsp-plugin.so planner libpython-plugin.so planner libsql-plugin.so planner libxmlplanner-plugin.so planner libstorage-mrproject.so.1 planner libstorage-sql.so planner The shlibs file could remain empty. For plugins this probably makes no difference, except when you have plugins that depend on other plugins. With shlibs even if the plugins are in the same package then dpkg-shlibdebs will fail if they match its patterns. If they are in different packages then dpkg-shlibdeps will miss dependencies because it ignores things not matching its pattern. With smybols files dpkg-shlibdebs matches the full SONAME and then it finds the right entry and dependency in all cases. So my proposed solution would be for dh_makeshlibs to stop creating shlibs files at all and create symbols files instead, with or without actual symbols as the user specifies. MfG Goswin PS: This concerns any private shared library (any dynamically linked shared object) outside /usr/lib and even some public shared libs in /usr/lib.
Goswin von Brederlow wrote: That is a pretty radical approach! Are we really ready to ditch shlibs files from Debian? What is an example of public shared libs that exhibits this problem?
Joey Hess <joeyh@debian.org> writes:
The entries are equivalent except that the symbols files matches against
the full SONAME instead of trying to split it. So nothing is lost while
something is gained.
W: ia32-libs: shlib-without-versioned-soname emul/ia32-linux/lib/libmemusage.so libmemusage.so
W: ia32-libs: shlib-without-versioned-soname emul/ia32-linux/lib/libpcprofile.so libpcprofile.so
or their native counterparts:
libc6: /lib/libSegFault.so
libc6: /lib/libmemusage.so
libc6: /lib/libpcprofile.so
Not /usr/lib but same thing.
MfG
Goswin
Goswin von Brederlow wrote: I agree in theory, less sure about practice. If someone can do enough tests, maybe propose a policy change (although policy does not *require* shlibs file), get a consensus, etc, then sure.
Joey Hess <joeyh@debian.org> writes:
Is Lukas Nussbaum still doing archive wide rebuilds? Maybe you could
give him a patched debhelper and let him rebuild all of debian and then
the resulting Depends could be compared.
Short of that how about an option --no-shlibs or --only-symbols that one
can use to get the alternate behaviour for packages where shlibs does
not work? I have tested it with ONE package where I create the symbols
files with just the sonames manually now. So I know it works in this
case. Doesn't have to be default.
MfG
Goswin