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


cheers, josch

Attachment: signature.asc
Description: signature

Pkg-javascript-devel mailing list

Reply via email to