Hi, It appears that your previous NMU of arpwatch introduced a couple of RC bugs (#550233 and #552792, both Cc'd) that you might not be aware of. Could you have a look at them, please?
In the changelog you wrote: * made /usr/share/arpwatch/ethercodes.dat a conffile so upgrades wont silently overwrite it if the user updates it. However, this violates Policy both directly (10.7.2, "Any configuration files created or used by your package must reside in `/etc'") and indirectly (10.7.3, "[These scripts handling conffiles] must not ask unnecessary questions"), resulting in those bug reports. Note that #552792 / Policy 10.7.2 / lintian "file-in-usr-marked-as-conffile" is now considered to be a "worse than RC" fatal error by the ftpmasters, and uploads with this lintian warning (even if overridden!) are automatically rejected from the archive. See: http://ftp-master.debian.org/~joerg/lintian/lintian.tags As a minimal fix for these, I suspect it would be sufficient to make /usr/share/arpwatch/ethercodes.dat not be a conffile again; if the user updates it, then reinstalls arpwatch, they'll lose their changes, but this file doesn't really seem like "configuration" to me, more like static data? A more elaborate version would be to treat ethercodes.dat rather like (say) ClamAV signatures, and keep it in /var/lib/arpwatch or something. As a starting point for this it'd be necessary to patch arpwatch and its updating scripts to use /v/l/a. After that, possibilities include: * Make arpwatch look in /v/l/a then fall back to /u/s/a; inform admins (e.g. in NEWS.Debian) that if they update the file, they must either keep updating it from then on, or delete /v/l/a/e.d to revert to the maintainer's version * If /v/l/a/e.d doesn't exist during postinst, copy it from /u/s/a, so that arpwatch only needs to look in one location * Do some sort of clever merge of /u/s/a and the admin's version (?) * Automatically remove or ignore the obsolete /v/l/a/e.d if it exists but is older than the maintainer version You presumably know better than I do how often ethercodes.dat varies, and therefore how worthwhile it is to expend effort on having an up-to-date version. (As an aside: NMUs that are new upstream versions should be versioned like 2.15a-0.1 to indicate that they're NMUs.) Regards, Simon
signature.asc
Description: Digital signature