[debhelper-devel] 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 07:47, Stephen Kitt wrote:
> Control: reopen -1
> Control: found -1 debhelper/9.20141222
> 
> Hi Niels,
> 

Hi Stephen,

> On Mon, 22 Dec 2014 00:36:05 +0000, owner at bugs.debian.org (Debian Bug
> Tracking System) wrote:
>> #747141: debhelper: dh_installdocs --link-doc forces source-version
>> dependencies
> 
> Unfortunately the bug I reported isn't fixed (see
> https://bugs.debian.org/747141#5 for my original message); with debhelper
> 9.20141222, I still end up with incorrect versioned dependencies between the
> arch: any packages built by gcc-mingw-w64: dh_installdocs adds a dependency on
> gcc-mingw-w64-base (= 14.3), where 14.3 is the *source* version and not the
> binary version (which is 4.9.1-19+14.3 in this case and correctly added by
> debian/rules).
> 

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.

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.

> 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.

> (gcc-mingw-w64 does this in a binNMU-friendly way.)
> 
> Regards,
> 
> Stephen
> 
> [...]

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).

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).
  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.

~Niels

[1] At least during the binNMU or, for compat 10, immediately.

[2] Upgrade the metapackage, hold the "real" package.  Requires the
upgrade changes license or/and copyright statements.