Re: dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self

[Justin Pryzby <justinpryzby@users.sourceforge.net>]

On Fri, Sep 09, 2005 at 06:17:50PM +0300, Eddy Petri?or wrote:
> On 9/7/05, Justin Pryzby <justinpryzby@users.sourceforge.net> wrote:
> > On Wed, Sep 07, 2005 at 07:59:29PM +0300, Eddy Petri?or wrote:
> > > On 9/6/05, Frank K?ster <frank@debian.org> wrote:
> > > > Justin Pryzby <justinpryzby@users.sourceforge.net> wrote:
> > > >
> > > > > Could someone else also comment on how applications should deal with
> > > > > shared libraries which are not intended to be used by other programs?
> > > >
> > > > If they aren't used by other programs, there's no need to produce a
> > > > library.  Perhaps it's convienient to create static libraries during
> > > > compilation and link against these, but shared libraries are of no use.
> > >
> > > there are two executables in the resulting package: qingy and
> > > qingy-DirectFB, so probably the library is a good choice (but in the
> > > same package.
> > Maybe, you could try statically linking with the library in both
> > binaries and see what the size impact is.  (The libraries have to be
> > compiled nonPIC for static code, and PIC for shared code, ultimately).
> 
> probably this doesn't make too much sense, imho
Why not?  Have you tried it?

> > Does your initial problem have to do with this line in
> > ./debian/control?
> > 
> >   Depends: ${shlibs:Depends}, ${misc:Depends}
> 
> yes, is the misc:Depends
Then you can get rid of that line in Depends, since its not doing
anything (as long as none of your dh_* commands are adding to it).

> > If one or both of those isn't defined, its not a serious problem.  The
> > package will build and run fine.  But, if you don't build any ELF
> > binaries, then you don't need to run (and probably shouldn't run)
> > dh_shlibdeps, and therefor shouldn't have the ${shlibs:Depends}
> > variable.
> 
> Hmm, I do build to ELFs...
> I removed the dh_shlibsdeps call, but then the package depends on itself :-/
Well, if you build any ELFs, then you need this command.

But, it actually makes some sense that the pkg depends on itself.
After all, it includes binaries which depend on libraries which only
it provides.  Maybe dh_* tools should include an exception for this,
mb not..

Is there a practical problem with a package which depends on itself?
Is it uninstallable?

> > ${misc:Depends} is apparently for dh_gconf, dh_installcatalogs and a
> > couple others.  zgrep misc:Dep /usr/share/man/man1/dh*
> > 
> > Have you read the example given in dh_shlibdeps.1?
> 
> As understood from that man page, the call is used with parameter -l
> when there are more binaries built out of the current source, which is
> not my case, while I didn't managed to make this package comile fine,
> apparently.
My understanding is that -L and -l are used when a given package
includes shared libraries as well as binaries depending on those
libraries, as is the case in your package.

Justin