[Top][All Lists]

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

Re: debian build of 0.35

From: Simon Josefsson
Subject: Re: debian build of 0.35
Date: Wed, 13 Feb 2008 16:54:54 +0100
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)

Russ Allbery <address@hidden> writes:

> 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.

Ah, I understand.

>> 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
> set.
> It's painful to fix.

I think we can defer this until less painful fixes (or patches) evolve,
it seems sub-optimal but difficult 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
> symbol).

Yeah, and if I recall correctly, using --as-needed isn't really
recommended from GCC upstream.  Further, --as-needed cause problems for
gnutls' configure script, and there may be similar code in shishi.


reply via email to

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