[debhelper-devel] Bug#747141: Bug#747141: Bug#747141: dh_installdocs --link-doc forces source-version dependencies (Was: Re: Bug#747141: closed by Niels Thykier <niels at thykier.net> (Bug#747141: fixed in debhelper 9.20141222))

[Niels Thykier]

On 2014-12-22 20:28, Stephen Kitt wrote:
> Hi Niels,
> 
> On Mon, 22 Dec 2014 08:25:03 +0100, Niels Thykier <niels at thykier.net> wrote:
>>> [...]
>>
>> Okay, I guess I realise what happens now that breaks your case.  We use
>> dpkg-parsechangelog -l.  During a binNMU this returns the binNMU
>> version (i.e. source version plus "+bX"), but I guess you set your own
>> binary version?  The best I can give you is the eqv. of a "pkg (=
>> ${binary:Version})".
>>   This minor modification (from our PoV) should not change the output in
>> the general case, and /may/ fix your case.
> 
> It should indeed, and it seems better to me generally speaking, since the
> dependency should be on the binary version anyway. There are other packages
> in the archive which produce binary packages with versions other than the
> source version!
> 

Ok, will do for Stretch.

>> However, if that does not work, then I am afraid your self-chosen
>> version scheme cannot be handled automatically by debhelper and you
>> would have to do the link-doc manually.  AFAICT for this to work, you
>> *must* use identical versions for the binary packages that are affected
>> by the "--link-doc" parameter.
> 
> In that case (and perhaps in general), what would be nice would be to have
> dh_installdocs allow the version to be specified; currently I run
> dh_installdocs then sed the substvars to remove the dependency
> added by dh_installdocs.
> 

Possibly, but I am not convinced.  The goal for debhelper is to make
"common" tasks easier and not to support every possible way of doing things.

>>> Regarding the arch: any to arch: all and vice-versa cases you fixed, what
>>> about transitional and/or metapackages? Given that they are empty, I
>>> don't see anything in Policy or in practice which would prevent arch: all
>>> metapackages depending on arch: any binary packages without a strict
>>> versioned dependency to provide their changelog and copyright...
>>
>> You cannot have a correct match between an arch:all and an arch:any
>> package during a binNMU (or at least, not until debhelper started
>> extracting the binNMU changelog parts into a separate file).  But then
>> you can only safely do it with an arch:all linking to an arch:any.
>>   However, with the interface debhelper provided, this never worked,
>> because we would generate a "pkg (= ${bVersion})" and after a binNMU the
>> arch:all version would still depend on the "old" ${bVersion} (since it
>> is not rebuilt).
>>
>> Instead of succeeding such a build and allow broken packages
>> (uninstallable) packages to reach the archive, we now error out[1].
>> This is especially helpful, since a lot of people seem to get these work.
> 
> Yup, I understand the reasoning behind the change. (I'm guessing
> s/work/wrong/ in that last sentence!)
> 

Silly typo on my part indeed.

>>> (gcc-mingw-w64 does this in a binNMU-friendly way.)
>>
>> Except, you are (at least, in theory) doing it very very wrong!  Your
>> metadata package does not force the exact version between itself and the
>> link-doc "target" packages.  This allows the versions to go out of sync
>> and we could (in theory) end up in a situation where the copyright file
>> do not accurately reflect the copyright/license statements of the
>> metapackage[2].
>>   Admittedly, for an "empty" metapackage, this example is a bit
>> contrived (as the "non-"content is hardly copyrightable).  However,
>> people might cargo-cult your setup into another package breaking theirs
>> (from a legal PoV).
> 
> It's the "empty" part I'm relying on ;-). That's why I was asking only about
> transitional and metapackages.
> 
>> I would strongly recommend getting this particular use-case (arch:all
>> metapackage -> arch:any non-metapackage) officially sanctioned before
>> using it.  Primarily to say it is in fact a valid use and secondarily to
>> highlight the cases, where it *is* valid (which is definitely far from
>> "all" cases).
> 
> That makes sense, I'll do that...
> 
>>   Even then, I doubt this is a scenario that debhelper will support out
>> of the box.  As mentioned, a fair share of debhelper users have gotten
>> this wrong, so I will go with the "safe-rather-than-sorry" approach here.
> 
> Yes, that seems perfectly sensible. As long as debhelper doesn't actively
> prevent it I won't complain!
> 
> Regards,
> 
> Stephen
> 
> [...]

I doubt we will actively prevent it from happening, but you will have to
implement link-doc manually for unsupported cases.

Thanks,
~Niels