Hi Craig, On Tue, Sep 01, 2009 at 10:57:30PM +1000, Craig Sanders wrote: > (Please CC me on replies as i'm not subscribed to debian-devel) > it's been a long time since I've done this, so i'd like to know what > the current etiquette is for an NMU. > arpwatch has had only sporadic NMU updates since 2004. I've packaged > the latest version and applied a bunch of patches from the BTS (all that > applied cleanly without conflicting with other patches), and fixed a few > other minor bugs. most of these bugs are years old. > I'd like to upload this to unstable, but i don't want to maintain the > package forever. I've mostly worked on this NMU because I wanted to > fix the sprintf for printing MAC addresses (zero-padded with %02x > rather than just %x), and decided I may as well fix some of the other > outstanding bugs too. > probably the only really controversial thing about this NMU is that i've > dumped the dbs-based packaging, and just gone with debhelper. I don't > have time to learn dbs and have no inclination to do so, either. i like > the *idea* of dbs but not the practice (i find it's a pain to work with > -- it was easier for me to re-package the latest version of arpwatch > from scratch than it was to figure out how dbs works just to make a > one-line change for the sprintf problem). given that arpwatch has hardly > been touched for the last few years, i'd guess that dbs is putting off > other potential NMUs or maybe even an adopter too. (Aside: dbs is a patch management system, and as such is orthogonal to debhelper. Indeed, arpwatch build-depends on debhelper *as well as* dbs.) I'm glad to see that Peter has approved of your NMU proposal, as migrating away from hand-rolled debian/rules files is a goal that I heartily support. However, your original question was one of etiquette, and I don't think that's been addressed in this thread. Yes, replacing the build system of a package in an NMU without the consent of the maintainer is an NMU "faux pas". :-) NMUers should limit themselves to changes that directly fix bugs, and steer clear of design decisions regarding the packaging. If some of those design decisions mean no one is willing to NMU the package and the package falls into disrepair as a result, then it's a candidate for orphaning via the QA team processes; but we shouldn't force the issue by replacing a build system we don't like with another that the /maintainer/ may dislike just as much when they come back to the package. Other "polite" conventions regarding NMUs are spelled out in the developer's reference <http://www.debian.org/doc/developers-reference/pkgs.html#nmu>. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature