Guillem Jover:
Hi!
Hi,
[...] Ugh, so from code staring and git log, it seems this has not worked since the code got added. Which should also mean the debhelper namespace which is documented in the spec does not work either. :/
I pulled out the debhelper keyword, so currently the debhelper namespace would be empty. I do not remember what we wrote in the spec. If it lists a concrete debhelper keyword, then I feel that is a bug in the example from the spec (as the keyword is not supported).
I've prepared the attached patch which I think should be fixing this, but will test and add some functional tests to check for this to make sure and avoid regressions.
LGTM without having tested it.
I might look into whether to target stable releases too given that it's a small fix (although no one else reported this until now, but that might only mean people thought this was allowed…). Thanks, Guillem
I think no body has had a reason for using a non-dpkg namespaced keyword up till now. I retracted the debhelper one because it does not work well in practice. I only discovered this because I wanted to introduce a R³ for debputy, where I feel it the usage would work in practice.
For the record, I have added said R³ keyword in debputy for the next release with a reference to this bug. I doubt it will create a lot of noise in the short term given debputy is "experimental-only" right now. It would have to be in a stable-backport before a stable update to dpkg would matter. And even then, the work around is for debputy to fallback to its internal assembly method or have the package degrade to "R³: binary-targets".
Best regards, Niels
