Hi Niels, On Mon, 22 Dec 2014 08:25:03 +0100, Niels Thykier <ni...@thykier.net> wrote: > > 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.
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!
> 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.
> > 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!)
> > (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
pgpZFdMVqDsVM.pgp
Description: OpenPGP digital signature
