Re: help with lintian issues
Please remember to do a group reply, i.e. keep the Cc: to -mentors.
Nothing private here :)
On Tue, Aug 27, 2002 at 10:02:59AM -0400, Joe Phillips wrote:
> > > W: libopensc0: package-relation-with-self depends: libopensc0 (>=
> > > 0.7.0-1isg)
> > > E: libopensc0: shlib-missing-in-control-file libscam.so
> > > usr/lib/libscam.so
> > >
> > > I'm not sure the root cause of these errors so here's some relevant
> > > info.
> > >
> > > I've created both shlibs.local and package specific shlibs file with no
> > > effect. If I remove them, I get more lintian errors.
> >
> > Can you paste the contents of your debian/shlibs.local?
>
> here it is:
>
> archaeopteryx{jaiger}$ cat debian/shlibs.local
> libopensc 0 libopensc0 (>= 0.7.0-1)
> libpkcs15init 0 libopensc0 (>= 0.7.0-1)
> libscam 0 libopensc0 (>= 0.7.0-1)
> libscconf 0 libopensc0 (>= 0.7.0-1)
> libscldap 0 libopensc0 (>= 0.7.0-1)
>
>
> As all of the above libraries are in the 'libopensc0' package, my
> libopensc0 shlibs file has the same contents.
The above error says "(>= 0.7.0-1isg)", so you must be picking that
dependency up from someplace else. Try removing any older versions of the
package, and running DH_VERBOSE=1 dh_shlibdeps.
> > > libscam.so isn't built with a SONAME or version, the other libraries
> > > are.
> >
> > libscan.so is either not a shared library, or a broken shared library, then.
> >
> > If the former, move it out of /usr/lib and into a private directory like
> > /usr/lib/something. If the latter, fix it by specifying the SONAME.
>
> I'll follow-up with the upstream on this. It seems to be a shared
> library. eg. 'file' reports shared library, ldd will read it and report
> its dependancies, some of the other binaries depend on it, etc.
>
> As for a broken shared library, that may hold some water. 'strip'
> doesn't like the file, there are other errors regarding the file when I
> build the package - though the make doesn't report any problems.
(make that strip --strip-unneeded, not merely strip)
> Any suggestions on other tests I could run on it in order to figure out
> what's wrong?
Find the linker line in the build system... for an exercise :) run objdump
-p on the file and see if it differs a lot from the others.
> Would adding a SONAME during build resolve some of these issues? In
> other words, does not having a SONAME cause the library breakage or
> could there be some other reason?
It doesn't cause immediate breakage, but it annihilates binary
compatibility. That is, once the contents of libscam.so changes one day, the
applications that used to link to it can crap out with linker errors, and
there is no way to prevent them from doing so, other than including the
versioned SONAME.
> > > What control file is referred to in the second error message?
> >
> > The file that gets installed into /var/lib/dpkg/info/libwhateverX.shlibs,
> > I'd guess. Anyway, don't bother figuring out the terse lintian output, only
> > the verbose one, with -i.
>
> -i output wasn't any more help to me on these two problems. It was
> helpful with a few other issues I had however.
File a bug against lintian so that the message can be fixed? :)
> > > I'm guessing in order to resolve the warning, I need to break the
> > > libopensc0 package into 4, one for each library.
> >
> > Not necessarily, but if you think that's right, go for it...
>
> Unless there's an immediate need, I will keep the libs in a single
> package. I don't see them being used independantly. libs that I could
> see used independantly have been broken out however (well maybe the ldap
> one can go to another package). For example, one of the other packages
> built from this source is a PAM library for smartcard authentication.
--
2. That which causes joy or happiness.
Reply to: