Hello, On Mon 13 May 2019 at 04:32PM -04, Scott Kitterman wrote: > I think for new packages (with the exception of new packages maintained in a > team that has a different pattern), it's not unreasonable. When starting from > scratch, dh is almost certainly no harder and usually easier than traditional > debhelper or other approaches. > > For existing packages, not so much. There are probably packages left that > would be trivial to convert, but I expect that most of those have been taken > care of already. For complex packages, this can be really hard to get right. > In the experiences I've had, converting packages that I maintain and have a > great deal of familiarity with is still fraught with error. > > For really complex packages, they are going to be hard for someone not > familiar with the package to modify regardless of dh/debhelper. My guess is > that if we try and push this direction the effort will mostly be spent where > there is the least potential for gain and the most risk of regressions. > > For improvement of existing packages, I think there are better things to > expend resources on. I agree with Scott's emphasis on the distinction between new and existing packages. Perhaps application of the distinction could be extended: perhaps there are other things that we could require of new packages, while creating no expectation that these requirements be met of older packages. In general, if a policy requirement or convention should apply to new packages, then it should apply to existing packages, too. But specifically where applying the requirement to an existing package is hugely more work than applying it to a new package, perhaps the requirement ought to be limited to new packages alone. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature