Bug#767839: [debhelper-devel] Bug#766711: debhelper: support --link-doc arch:all <=> arch:any
On 2015-01-09 17:39, Niels Thykier wrote:
> [...]
>
For reference, I have reviewed the situation a bit more and I have some
updates to my previous statements.
> If you bump the version of the binary, then it is no longer the same
> version as the source package. Which is why I believe it is a violation
> of the footnote example.
>
I still believe this to be mostly true. But to be honest, that is the
least of my concerns with this problem.
Please note that permitting arch:any packages to use an arch:all package
as --link-doc package implies that the arch:any package is allowed to
install its "binNMU" changelog into the target package as:
/usr/share/doc/<target-package>/<changelog>.<arch>
There are already cases where debhelper might do something similar with
--link-doc packages, so I doubt this is an issue.
> Regardless, debhelper *cannot express* a dependency relation that
> guarantees that binaries built from exactly that version of the source
> (including binNMUs thereof) *AND* supporting arch:all <-> arch:any
> --link-doc support *WITHOUT* breaking binNMU.
>
> [...]
>
> Thanks,
> ~Niels
>
> [...]
While my argument here might be true, it is only so for cases where the
--link-doc target is an arch:any package. In the case where an arch:any
uses an arch:all package as --link-doc target, a dependency on
(pkg = ${source:Version}) does seem to retain binNMU safety at first glance.
I am open to patches that allow an arch:any package to use an arch:all
as --link-doc target *provided* that:
* It detects "invalid link-doc targets"[1] under a regular source
*AND* an "arch:all only" (-A) builds[2]. Invalid link-doc targets
must cause an errors and abort the build.
* The detection must *not* break a binNMU build[3].
* The patch must ensure that the binNMU changelog is installed into the
target package as noted above.
- If this cannot be done without changing the debhelper sequence,
the --link-doc change can only be supported in a new compat level.
- NB: If it requires a major change to the sequence, I might veto it
solely on that basis.
* The patch cannot make assumptions on maximum number of packages
sharing the same --link-doc target[4].
* The patch cannot make assumptions on all packages sharing the same
--link-doc target will be included in the same dh_installdocs call.
* The patch must not introduce file conflicts. A likely example could
when multiple arch:any packages share the same arch:all package as
link-doc target.
* The patch must ensure that as long as at least one of the arch:any
packages are installed, their binNMU changelog is available in
/usr/share/doc/<target-package>[5].
* It does not cause regressions in debhelper's current functionality
or/and behaviour.
- Where the existing behaviour is wrong or can be extended in an
incompatible manner, the support can be added in a new compat level
as noted above.
* The patch must implement policy compliance under the current
interface[6].
- If not possible, it may extend the interface in a new compat level.
However, the interface should generally strive to retain it
simplicity. In particular, it *must not* require the user to
pre-declare the packages using a given --link-doc target (or
similar) as such can trivially become outdated.
* The patch must use the proper version for the --link-doc target.
- For an arch:all target, I suspect the best approximation will be
the ${source:Version} variable. Though I suspect it to be wrong
for cases where packages choose a different own version for the
target package (see #747141). This *may* be documented as a known
limitation of the --link-doc setup if a better solution cannot be
provided[7].
I am not entirely sure that this is possible, but to be honest, I would
be quite interested to see a solution to this problem.
In fact, I might be willing to apply such a patch to debhelper even
without the policy footnote clarified[8] (in this bug or in the policy)
assuming it satisfies the above requirements. Note that there are also
some *implicit* requirements (basics like it does not break the test
suite etc.) that I have not spelled out.
Mind you, should a later clarification render this case non-compliant,
I will be forced to deprecate/revert the provided patch.
Should you provide a patch, please remove the "wontfix" tag from #766711
and add the "patch" tag as well.
Thanks,
~Niels
[1] An "invalid link-doc target" being an arch:all using an arch:any as
link-doc target.
[2] The reason here is that it is currently permitted to upload source
plus arch:all packages to the archive. I believe that debhelper should
stop these from reaching the archive.
[3] I believe the test case should be something like:
dch --bin-nmu 'Fake binNMU'
dpkg-buildpackage -B -us -uc
[4] However, the patch may assume that a --link-doc target *never* have
another package as --link-doc target (e.g. P links to Q which links to
R). This case is not supported right now in all cases, and I consider
it mostly a theoretical problem.
[5] The content of these changelogs will be the same, so it does not
matter which of them provides it. However, being a binNMU changelog, it
cannot be provided by the arch:all package.
[6] I.e. the --link-doc=<pkg> argument to dh_installdocs.
[7] I am not aware of one and this is how it works today with link-docs
between arch:all packages, so it would not be a regression)
[8] For the purpose of implementing this, we assume that this case is
policy compliant until otherwise noted.
Reply to: