There is this little known feature of dh-make-perl, the overrides,
that I want to drop.
The overrides is a mechanism to forsibly correct some values that
dh-make-perl guesses wrong. These include package name, source package
name, section, priority, dependencies (all three kinds of),
description, long description, version, architecture, extra fields to
source and binary control stanza, and maintainer. It is like supplying
a partial debian/control file which takes priority over the values
dh-make-perl detects.
The override mechanism is implemented by sourcing (perldoc -f do) the
overrides file, which is expected to modify ${overrides}{Dist-Name}.
I find this feature a gross hack coming from the times when
dh-make-perl was a little puppy. I guess it is much less usable now,
when dh-make-perl is more like James P. Sullivan and even has
--refresh. I think that when dh-make-perl makes a wrong guess, we need
to know and fix it, instead of providing a patch system. Having code
run in user context also gives me an uneasy feeling.
I think overrides are hardly ever used, and would like to try to phase
them out. I suggest a three stage process:
* declare overrides as deprecated. The sample override file is moved
to examples and marked as deprecated with a pointer to this thread
for "objections".
A warning is issued whenever an override file is discovered.
Everithing still works as before.
* wait for some months (squeeze?) for feedback from users.
* either drop it or keep it (but with rationale)
Alternatively, we may drop the feature right away, issuing a warning
("overrides no longer used") when an override file is found and see if
we get any bug reports :)
Please speak up if you have a use case for overrides or know someone
who uses them. Note that overrides are not used during --refresh, only
during --make.
Attachment:
signature.asc
Description: Digital signature