On Thu, August 24, 2006 19:24, Russ Allbery said: > Martin-Éric Racine <[EMAIL PROTECTED]> writes: > >> Package: lintian >> Version: 1.23.23 >> Severity: normal > >> I have been getting this error on my package for a long time: > >> E: planner binary: duplicate-entry-in-shlibs-control-file libmrp > >> /usr/lib/planner/ >> |-- file-modules >> | |-- libmrp-xml.so >> | `-- libmrp-xsl.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? > > This error isn't about the files stored in your package; rather, it's > about the shlibs control file in your package.
Yes, indeed. > The contents of the file are: > > libplanner-1 0 planner > libmrp xml planner > libmrp xsl planner That's what the error seems to be: it looks as if the shlibs is being parsed as meaning that anything following the first dash in the filename should end up as the second field of the shlibs file. > 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. That is generated by dh_makeshlibs from debhelper. Could this be where this parsing bug is? > 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. [...] > 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. Valid point. I might indeed simply exclude them. -- Martin-Éric Racine http://q-funk.iki.fi