[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
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390882
>>
>> 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.
/Simon
Re: debian build of 0.35, Russ Allbery, 2008/02/07
- Re: debian build of 0.35,
Simon Josefsson <=