[Pkg-privacy-maintainers] Bug#859121: RFP: genmkfile - Generic Makefile
intrigeri at debian.org
Fri Mar 31 05:44:20 UTC 2017
[emailing the team only, not the RFP bug, as what I'm writing below
is really only about using genmkfile in the pkg-privacy-maintainers
team, and I don't care this much about whether genmkfile makes it
into the archive per-se]
> Makes packaging scripts simpler. No more need to manually maintain 'make
> install' targets or distribution specific install files such as
> Files in etc/... in root source folder will be installed to /etc/...,
> files in usr/... will be installed to /usr/... and so forth. This should
> make renaming, moving files around, packaging, etc. very simple.
Does it handle renaming of conffiles properly?
> Packaging of most packages can look very similar.
… but different from the other packages that are already in the
> Provides common make targets such as 'make install'. Very extensible
> through file ./make-helper-overrides.bsh or folder
> ./make-helper-overrides.d. By using overrides, any make target can be
> easily extended using pre or post hooks or replaced.
Frankly, I'm not at all thrilled at the idea of team members who want
to give a hand with the onion-grater packaging having to learn yet
another packaging tool and its own ways to implement various kinds of
overrides. But perhaps I've misunderstood something: in a package
that's built using genmkfile, can I still use the power of debhelper,
or do I need to use genmkfile-specific tools for every bit of work
that debhelper already provides an abstraction layer for?
> use case:
> onion-grater would be a great addition to Debian because it would
> improve usability for users that use applications using Tor's ControlPort.
We have plenty of Python software in the archive already (see e.g.
onionshare and tails-installer), and a number of packaging helpers for
Python too. The Python packaging helpers I know:
* are built on top of Python standard build/install tools: this is
nice as the distro-agnostic parts can live upstream and benefit
non-Debian operating systems;
* know quite a bit about Python-specific stuff, such as installation
paths for libraries depending on what versions of the Python
interpreter is supported; I suspect that will be helpful whenever
onion-grater is refactored and gets some bits extracted into
a library (as opposed to being a single script).
So I'm wondering: why do we need yet another packaging helper?
Will it support extending beyond the current simplistic state of
onion-grater, without having to write new code to add features that
other packaging helpers already support?
More information about the Pkg-privacy-maintainers