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, ow...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
