Re: "not-binnmuable-all-depends-any" problem exists for Multi-Arch: foreign, too?
On 09/30/2015 05:39 PM, Christoph Biedl wrote:
> Johannes Schauer wrote...
>
>> Quoting Christoph Biedl (2015-09-30 08:25:50)
>>> Personally, I'm not happy about adding extra magic to version numbers
>>> to identify binNMUs and would rather introduce a way to define a range
>>> of version numbers a package satifies, like in
>>>
>>> | Version: 5.25-3+b1 # upper bound
>>> | Also-Satifies: 5.25-3 # lower bound
>>>
>>> or by allowing two version numbers in the Version: header. But that's
>>> certainly not my cup of tea, and might bring in a huge amount of new
>>> problems I cannot even imagine yet.
>>
>> in fact, this can already be done:
>>
>> Package: foo
>> Architecture: any
>> Version: 5.25-3+b1
>> Provides: foo (= 5.25-3)
>
> Oy! So what's the reason those who trigger binNMUs do not utlize this
> feature? Then packagers can abandon this ugly and fragile
> foo (>= ${binary:Version}), foo (<< ${binary:Version}.1~),
> dependency construct.
That was my first thought, too, when I read it - why not just add a
"Provides: foo (= ${source:Version}).
One reason against: in case of a binNMU we still need the strict
dependency on binary:Version from other Arch: any packages of the same arch.
Greets
jre
Reply to: