Control: clone -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11 -12 -13 -14 -15 Control: reassign -2 src:biff Control: retitle -2 biff misses the generator for configure Control: reassign -3 src:bsd-finger Control: retitle -3 bsd-finger misses the generator for configure Control: reassign -4 src:linux-ftpd Control: retitle -4 linux-ftpd misses the generator for configure Control: reassign -5 src:linux-ftpd-ssl Control: retitle -5 linux-ftpd-ssl misses the generator for configure Control: reassign -6 src:netkit-bootparamd Control: retitle -6 netkit-bootparamd misses the generator for configure Control: reassign -7 src:netkit-ftp Control: retitle -7 netkit-ftp misses the generator for configure Control: reassign -8 src:netkit-ftp-ssl Control: retitle -8 netkit-ftp-ssl misses the generator for configure Control: reassign -9 src:netkit-rsh Control: retitle -9 netkit-rsh misses the generator for configure Control: reassign -10 src:netkit-rusers Control: retitle -10 netkit-rusers misses the generator for configure Control: reassign -11 src:netkit-rwall Control: retitle -11 netkit-rwall misses the generator for configure Control: reassign -12 src:netkit-rwho Control: retitle -12 netkit-rwho misses the generator for configure Control: reassign -13 src:netkit-telnet Control: retitle -13 netkit-telnet misses the generator for configure Control: reassign -14 src:netkit-telnet-ssl Control: retitle -14 netkit-telnet-ssl misses the generator for configure Control: reassign -15 src:netkit-tftp Control: retitle -15 netkit-tftp misses the generator for configure
On Sun, Oct 28, 2018 at 11:19:47AM +0100, Christoph Biedl wrote: > Still you have a practical point as mentioned in #873085: The generated > configure has bugs, even some more (bashisms, reported outside Debian), > and it's way better to fix this in the generator than in some 15 > packages. I think this is the sticking point. The requirement for source is there to make modifications feasible. Of course we can patch bugs in binary files, but it becomes prohibitively expensive. The same is true for fixing the same bug in 15 packages. For this reason, I think that we do violate the DFSG here. > It seems however the mentioned confgen program is lost in the void. > I've been looking around quite a lot, but no avail. So I've contacted > David A. Holland[1], asking for advice. As a plan B, I might as well > re-implement that confgen program and make it part of the build > process. But I'd do that only as a last resort only: At least some of > the packages have a significant popcon count, so RM isn't an option. It seems fairly obvious now that we'll have to touch all those 15 packages one way or another. Whether we add confgen or replace the build system altogether is an open question, but both involve changing all affected source packages. Given this, I'll clone the respective bugs. That in turn means that reducing the scope using RM bugs (for some) sounds useful. I'm not sure that adding our own confgen is maintainable in the long run. We already have very many build systems in Debian. We've learned the hard way that supporting many different build and packaging tools is expensive. Nowadays, most packages use debhelper and that kind of centralization bears benefits in modifiability. So I wonder whether outright replacing confgen usage (effectively reimplementing the build system for <= 15 packages) would be more maintainable in the long run. Most likely, that would make cross building just work. On the other hand, we'd have to extend the prospective confgen to support that use case. I'm suggesting that rewriting all those build systems using one of the standard tools (e.g. autotools, cmake, meson, maybe not qmake, ...) could mean less work. Helmut
