Bug#1054368: debhelper: Does not support double build (possible violation of Policy 4.9)
Hello Niels, thanks for your reply. Am Wed, Oct 25, 2023 at 03:32:47PM +0200 schrieb Niels Thykier: > 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). Ok, so then #1047898 is "just" about the gmo files. > > 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. Thanks. Then I check how to deal with them (possibly upstream). > 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). Thanks for your pointer. > > 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. Well, I'm trying to find the root cause, and as stated I just use plain dh, so I don't know where I should have looked at. Maybe you could introduce a pointer to better / correct documentation then? > > 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. This is a plain autconf system. When I took it over (as upstream), I tried to keep as close to the (info) documentation as possible on any extension. Though, I admit, that I only "understand" a small part of it. > 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 Which I don't know, but > * Telling dh_clean to purge the `*.gmo` files > (`echo 'po/*.gmo' > debian/clean` should do), OR by Thanks, this is a good hint! > * Repacking the upstream tarball to not include the binary files being > mutated in the first place. As I'm upstream as well, I can update the upstream system to do this. > 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 Sorry, I'm not a "real" programmer. I just respond to #1047898 where I was informed that an RC bug might come in. I'm currently just learning where the problem is and I have no idae of the inner working of dh. > * 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. Well, I want to fix #1047898. And until now I (mis)understood that the best package guidance is to use dh, as it encodes policy. If you say this is not the case, then I mainly learned that this is not the case. And again, thanks for the pointers. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de
Bug#1054368: debhelper: Does not support double build (possible violation of Policy 4.9)
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
Bug#1054368: debhelper: Does not support double build (possible violation of Policy 4.9)
Package: debhelper Version: 13.11.4 Severity: minor User: debian...@lists.debian.org Usertags: qa-doublebuild Some time ago my package linuxinfo aquired a bug (#1047898) whereas dpkg-buildpackage ; dpkg-buildpackage -S does not work. And if fact, it does not. The reporter informed me that this is a potential violation of Debian Policy section 4.9 (clean target), but that this was under discussion at the time of the reporting. 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. In the past I had an explicit debian/rules, but to ensure compliance with the ever evolving Debian Policy I made it on purpose very simple: include /usr/share/dpkg/architecture.mk ifeq ($(DEB_HOST_ARCH),amd64) confflags += --with-pcre else ifeq ($(DEB_HOST_ARCH),i386) confflags += --with-pcre else ifeq ($(DEB_HOST_ARCH),x32) confflags += --with-pcre endif %: dh $@ override_dh_auto_configure: dh_auto_configure -- $(confflags) As you can see, I only add (architecture dependend) configuration flags for linking with pcre. dh seems to delete quite a few files shipped in the package. 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). 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). 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. -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
