On Tue, May 14, 2019 at 02:30:52PM -0400, Sam Hartman wrote: > How do we feel about people making build system conversions when those > conversion make it easier to fix some other bug that they are fixing as > part of an NMU? > That is, imagine that a package is mishandling the combination of > systemd units and an init script. As someone preparing an NMU, is it > reasonable to move to dh compat 12 from some other build system if I > believe doing so will make it easier for me to fix the bug and verify > the fix? I see various scenarios: - if a package is generally actively maintained, except the maintainer is currently unresponsive for some reason and there is a RC bug to fix, I could understand frowning upon a build system conversion in an NMU. - if a package has bugs that can all be fixed trivially with a build system conversion, I would see no reason not to do such a conversion, even in an NMU. - a change of build system in a complex package would be more controversial than in a trivial package. - if a package has had an inactive and unresponsive maintainer for a long time, it would indeed be a case for salvaging. I could however imagine someone having enough energy to dust off old packages in the archive, while not having enough energy to pick up maintenance of lots of old dusty packages. I would consider the idea of salvaging+orphaning, like following the salvaging procedure but setting the maintainer to qa instead. - I'd say that orphaned packages can be uncontroversially be converted to dh. With a consensus of having dh as the default build system, and the understanding that some packages have good reasons not to use dh, I'd like a way to tell when a package is not using dh for a reason, from when a package is not using dh because the maintainer has not gotten around to it yet. I'd propose to recommend dh as the default build system, and document in README.source if there are reasons to use something else. At that point, one could look at README.source to see if changing build system would be an possible strategy for fixing bugs in an NMU. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>
Attachment:
signature.asc
Description: PGP signature