Control: tags -1 wontfix
Helge Kreutzmann:
Package: debhelper
Version: 13.11.4
Severity: minor
User: debian...@lists.debian.org
Usertags: qa-doublebuild
[...]
I first checked (my) upstream build system. Except for one stamp file
(which is *much* less than done by debhelper) the build is idempotent,
i.e.:
./configure && make && make clean
returns the sources into the state as shipped.
[...]
dh seems to delete quite a few files shipped in the package.
Deleting files shipped in the package is a non-issue (dpkg ignores that
with a warning).
For me, this is a clear bug in dh, as linuxinfo just uses it plain and
there is no "manipulation" of build files happening (on purpose).
The root cause seems to be that the upstream tarball contains binary
".gmo" files that will be regenerated when you build with dh and are not
reset/deleted when you clean.
Most likely this is a consequence of dh_autoreconf (which is not
debhelper but a separate package that debhelper depends on) or
`dh_auto_clean` using `make distclean` rather than `make clean` (as you
tested with).
I checked dh_clean(1) and dh(1), but could not find any mention of how
to modify this (which I would not have expected anyhow).
Both `dh_clean` and `dh` are red herrings in this case.
If the severity of 1047898 is changed, then I will change this one (as
it is the root cause). In linuxinfo I probably could work around this,
by backing up all affected files before clean and restoring them after
clean (using an override). But this is a band aid, not a solution.
From my point of view, running an upstream build system is running
arbitrary code. There is no way debhelper can reliably detect and manage
all possible variations of upstreams and how they implement
"./configure" vs. whether they include binary .gmo files in their source
tarball that may or may not be regenerated during build and how they
structure their source code internally.
As a consequence, it is my view that the root cause is not solely
debhelper and that you will have to work around this in your package
somehow. This could be by:
* Disabling dh features that cause this problem, OR by
* Telling dh_clean to purge the `*.gmo` files
(`echo 'po/*.gmo' > debian/clean` should do), OR by
* Repacking the upstream tarball to not include the binary files being
mutated in the first place.
As the maintainer of debhelper, this is my principle stance on this
matter. If you disagree, you are welcome to either:
* provide a "small non-intrusive" patch that solves your problem
without causing a significant number of regressions. Onus is on
you (whoever providing the patch) to research alternatives, and, if
the patch is controversial/likely to break other packages, provide
archive-wide test results and as necessary show project wide
consensus on debian-devel, OR
* raise this issue to the tech-ctte according to constitution 6.1.1
(AFAICT). However, if you do put this before the tech-ctte, be
advised that they cannot do detailed design work (constitution
6.3.5). This means for them to make a decision someone else has to
come up with a practical technical solution that they can vote in
over the status quo. And by doing that, that someone might as well
provide a patch per the first bullet point because the tech-ctte
will probably have the same questions/requirements as I laid out
above.
Best regards,
Niels
