On 2014-12-22 20:28, Stephen Kitt wrote:
> Hi Niels,
>
> On Mon, 22 Dec 2014 08:25:03 +0100, Niels Thykier <ni...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
