On Fri, 29 Dec 2017 at 21:06:05 +0100, Bill Allombert wrote:
> It would be more useful to kept it but to add a note toward migrating to
> uscan if possible.
If this is reinstated, please can we discard the requirement that
get-orig-source be invokable with an arbitrary working directory?
Many packages don't do that (because it's much more difficult to achieve
than it looks), so clearly nobody is actually able to rely on it.
We seem to have three categories of get-orig-source, that I've seen:
- ignore that requirement, rely on dpkg's default.mk, get-orig-source
will just fail when invoked from some other directory (very common),
technically a Policy violation (example: gnome-shell-extension-caffeine)
- obey that requirement by duplicating information that exists elsewhere
in the source package, meaning maintainers can't copy the same
get-orig-source implementation into multiple packages with similar
upstream patterns (example: iortcw)
- obey that requirement by doing "clever" (non-obvious, fragile) things
with $(MAKEFILE_LIST), usually triggering Lintian warnings for having
used dpkg-parsechangelog instead of default.mk because default.mk
can't work with that pattern (example: mpdris2)
The first seems the least bad to me, although I've tried all three.
In my own packages that have a get-orig-source (mostly those where I
have to use git snapshots or delete large non-free subtrees or both),
I usually end up implementing a maintainer-get-orig-source target that
wraps get-orig-source to make it work the way I want it to.
smcv
