Guillem Jover wrote... > I'd be interested to know about those scenarios (or abstract descriptions > of them), to be able to understand the required semantics for this, or > whether there are other alternatives?
Well, the particular use case is not fully the Debian way to do things:
It's an in-house policy where Debian packages are used to distribute
software, but debian/changelog is considered redundant information for
the following reasons:
* The list of changes can be taken from git as well.
* The source package name can be taken from debian/control.
* The source version number follows a certain schema that can be derived
from some other information.
Now dpkg-buildpackage still needs debian/changelog. No problem on the
build host where that file can be auto-generated in a step between
unpacking the sources from git and starting the build.
There are however also local, interactive builds, Something the
developers do to test buildability of a package and similar stuff. They
still should just use dpkg-buildpackage, so a hook was handy: It would
run the changelog-generator, and then things would work as expected. The
existing "init" hook however is executed too late for hat, hence the
proposal.
Other solutions exist as well, like some wrappers - but embedding this
in dpkg-buildpackage and shipping a configuration file that defines the
hook has one charme: It eases training new employees who already have
some Debian skills.
Regards,
Christoph
signature.asc
Description: PGP signature
