Sandro Knauß:
> Control: tags -1 - moreinfo
>
> Hey,
>
>> Can you expand a bit on the use case here or the problem you want to
>> solve? At the moment, I cannot see how it is different from having the
>> following in your d/control file
>>
>> """
>> Depends: other-package (= ${binary:Version}), ...
>> """
>>
>> (Except this one goes in d/control and the case you point to goes in
>> d/rules)
>
> you are right, that you can solve the issue with adding this dependency in d/
> control explicitly. The approach I described also works with with any kind of
> dependency that end up in the Depends via a variable like ${shlibs:Depends}
> or
> ${misc:Depends}. So you can rely on the dh to get the correct dependencies
> and
> updates it to a equal version dependency for package internal ones and don't
> need to list the inter package ones explicitly.
>
> hefee
>
Ok, getting dependencies "right by default" is as good a reason as any
to support it the conceptual idea (among other because strictly-equal
version dependencies are fine between same-source binaries).
However, I am not going to fiddle with debian/shlibs.local because it
is fragile and it would break horribly if people need that file for
other reasons (plus it would complicating clean up).
So a prerequisite for this is that dpkg-shlibdeps support multiple
shlibs.local files. @Guillem: What is your take on this bit? Preference
order would be "d/shlibs.local", "file(s) passed via this new option",
<whatever the remaining preference order was before>.
If it is any easier, I am also fine with the option neutering
d/shlibs.local as long as I can pass multiple files (so I can emulate it
with the option).
Thanks,
~Niels
