[Pkg-privacy-maintainers] Bug#859121: RFP: genmkfile - Generic Makefile

[intrigeri]

Hi,

[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]

Patrick Schleizer:
> Makes packaging scripts simpler. No more need to manually maintain 'make
> install' targets or distribution specific install files such as
> debian/pkg-name.install.

> 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
Debian archive.

> 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?

Cheers,
-- 
intrigeri