[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: debian build of 0.35

From: Russ Allbery
Subject: Re: debian build of 0.35
Date: Thu, 07 Feb 2008 12:40:45 -0800
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

Simon Josefsson <address@hidden> writes:

> I'm building 0.35 now, to be able to give #423944 back to the inetutils
> package.  There are minimal changes compared to 0.34, so it builds fine,
> but I started to look at some of the warnings.
> Several of the packages result in:
> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> Isn't there a ${misc:Depends} variable?  Searching on the web yields a
> lot of similar warning messages, but I didn't found how people solved
> it.  Should we remove that dependency?

This is a long-standing minor annoyance.  The recommendation is generally
to just leave it.  Basically: if there is anything that debhelper needs to
do in the maintainer scripts that creates additional dependencies, it will
add those dependencies to ${misc:Depends}.  However, if there are none, it
won't create the substvar, and you'll get warnings.  So you can remove it
if debhelper isn't creating it, but then if something changes about the
package later and you end up needing those dependencies, you have to add
it back in.

> Then there are a bunch of warnings as below.  I suspect these are
> related to
> but I'm not sure whether it is useful to spend time to try to fix this
> for this particular package, as I discussed in that bug report.  I don't
> recall seeing the warning from dpkg-shlibdeps before, so maybe there has
> been some policy change in debian?

Indeed, that's the same issue.

The only thing that's changed is that dpkg-shlibdeps now warns.
Otherwise, the situation remains the same.

> I suspect to fully solve this, changes may be needed in the *.la file
> from gnutls, libidn, libtasn1 etc too.  Alas, I'm upstream for those as
> well..

Yes, libtool is very bad at handling this since it doesn't have a notion
of libraries needed only for static linking and not for dynamic linking,
and hence includes the full dependency list all the time.  For my packages
where I've fixed this, I've had to bypass and not use the libtool *.la
files when linking in order to reduce the dependencies to the required

It's painful to fix.

One possible alternative is to link with --as-needed, although that has
been known to cause problems on some of the more obscure Debian
architectures in the past and to miss dependencies that should still exist
(such as if one uses a data type from another library but not a specific

Russ Allbery (address@hidden)             <>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]