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

Attachment: signature.asc
Description: Digital signature

Reply via email to