beuc@debian.org:
> Hi,
>
Hi,
Relying as the debhelper maintainer.
Let me start by answering, where we are now (in compat 10). In compat
10, we got a simple narrow permitted set, where we can say:
* The selections are /known/ to work in all cases.
* They are simple to implement (correctly).
* It is simple to understand when you can apply it
("all -> all" OR "any -> any")
* debhelper rejects known cases that it does not support correctly
The last part is missing in earlier compat levels.
> There are a few new bugs related to this, perhaps because it's common
> practice in game packages, that split <package> and <package>-data,
> and move all the doc to <package>-data.
>
> I ended here reading:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857974#15
> "That is broken by design: #766711"
> though apparently this is more a problem of implementation rather than
> a design issue.
>
It is a common perception among people who are quite happy with
--link-doc that is "just an implementation issue". Unfortunately, from
the implementation PoV there are some fundamental design issues that a
lot of people are not aware of.
Especially, if you want to keep both design and implementation simple.
I will get to that below.
> I see that DH now generates an error with compat=10, but the
> documentation doesn't hint at this issue.
>
Correct on debhelper erroring out in compat 10.
* It is the first time that (I remember where) someone has mentioned
that the documentation is inadequate.
* Please file a bug against debhelper on what you are missing from the
documentation. You are almost certainly right on this; just let me
know what I have overlooked.
Originally we wanted to error out in compat 9, but only during a binNMU.
Unfortunately we could make the detection work correctly so it had too
many false-positives (although in hindsight I think I could do a follow
up with less issues now).
> Also AFAICS the current binNMU changelogs created with such a
> configuration are lost (the binary package just contain the <package>
> -> <package>-data symlink and no changelog.<arch>).
> This looks like the main/only issue to me.
>
Unfortunately, this is a common misconception. But lets dig deeper to
understand the issue.
It is correct that if we did an:
arch:any (<package>) -> arch:all (<package>-data)
link-doc, we would have to ensure that the changelog.arch file was
included / preserved so it appeared in the arch:all's doc dir despite
being provided by the arch:any file.
But then what happens when /two/ (or more) arch:any packages want to use
the same arch:all with --link-doc. Now they both install the same file
to the same location which causes a file-conflict. Still RC, still
broken and still "debhelper's fault".
Also, this reveals that the previous part of pushing the
changelog.$arch file through the symlink must /only/ occur if the target
is arch:all. Otherwise you bust arch:any -> arch:any link-docs on
binNMUs as well (another RC bug just around the corner).
And you might think that debhelper would be able to detect these cases
reliably. However, that gets extra complicated as debhelper cannot rely
on this being in the same dh_installdocs call, because you can do stuff
like:
dh_installdocs -ppkg1 --link-doc=pkg-data
dh_installdocs -ppkg2 --link-doc=pkg-data
...
dh_installdocs -ppkgN --link-doc=pkg-data
Plus then --link-doc becomes even more magical to understand. You can
do all -> all, any -> any and any -> all, but the latter only works for
one pkg (while the rest works for "unlimited" numbers). Without
mentioning the people lobbying for support for arch:all -> arch:any.
Compare this to what is supported in compat 10:
* The selections are /known/ to work in all cases.
* They are simple to implement (correctly).
* It is simple to understand when you can apply it
("all -> all" OR "any -> any")
* Unsupported cases are rejected at built time (and thus never reach
the archive).
This is so much easier to deal with as a consumer and for me as the one
having to support it. I am sorry it excludes your desired state, but
that unfortunately fails at least 2 out of bullets of the above.
> Would you provide a status update?
> (are changes/clarifications planned?)
>
> Cheers!
> Sylvain
>
The current status is that I intend to deprecate compat 9 in buster and
migrate people to compat 10, which prevents binNMU unsafe cases before
they reach the archive and that will be the end of that.
However, I doubt I would be motivated to write support for arch:any ->
arch:all in debhelper even if they are blessed by policy.
In summary:
* The compat 10 rules are simple to implement, understand, explain and
we know they work in all cases.
* Please file bugs for debhelper's documentation of --link-doc where it
is not up to date/adequate.
Thanks,
~Niels
Attachment:
signature.asc
Description: OpenPGP digital signature