Quoting Jonas Smedegaard (2017-07-05 21:04:44) > Quoting Johannes Schauer (2017-07-05 18:26:40) > > Maybe I misunderstand but this bug report is not about "changing" or > > "bumping" anything. > > > > Since npm2deb creates the *initial* Debian packaging, the situation > > where we start with a lower Standards-Version and then have to verify > > changes before we can "bump" the Standards-Version doesn't arise. > > Right, this is not about single package bumping as I confusingly wrote, > but instead about automated processing where it is even _more_ important > to verify that the claimed Standards-Version is accurately applied, and > even _more_ important to consider if newest shiny denhelper really is > needed!
Lets not conflate the two issues. I assume that it's uncontroversial that the newest Standards-Version should be emitted because it doesn't make sense to pick any old policy version and then require the maintainer to bump the version bit by bit, right? > > Furthermore, I'd argue that any tool which auto-generates Debian packaging > > data should use the current and/or recommended packaging practices. > > According to the debhelper man page, compatibility level 10 is the > > "recommended mode of operation". > I am aware that the developers of debhelper promote newest major version - > that does not change my plea about being more conservative: Use the debhelper > compatibility level supported in oldstable (currently 9), unless some feature > requiring a newer compatibility level is needed. I will leave the choice about the right debhelper version to the npm2deb maintainers. Thanks! cheers, josch
signature.asc
Description: signature
