How can I properly override logrotate policies?

First of all, I recommend using a tool such as etckeeper to keep track of changes to files in /etc; that avoids data loss during upgrades (among other benefits).

The “correct” way to override the definitions is to edit the configuration files directly; that’s why dpkg knows how to handle configuration files and prompts you when upgrades introduce changes. Unfortunately that’s not ideal, as you discovered.

To actually address your specific configuration issue, in a Debian-friendly way, I would suggest actually logging your mail messages to a different log file, and setting that up in logrotate:

• add a new log configuration file in /etc/rsyslog.d, directing mail.* to a new log file, e.g. /var/log/ourmail.log (assuming you’re using rsyslog — change as appropriate);
• configure /var/log/ourmail.log in a new logrotate configuration file.

Since this only involves adding new configuration files, there’s no upgrade issue. The existing log files will still be generated and rotated using the default configuration, but your log files will follow your configuration.

In Debian, one way to keep copies of configuration/binaries different from the intended by the defaults of the distribution, is "diverting" the file. e.g. telling the package manager when installing/updating to new versions of any deb package, to install a particular file to another directory out of way.

I have been using the dpkg-divert functionality to keep an init.d sys V wrapper for BIND and ISC-DHCP for years, that checks the DNS and DHCP configuration files for consistency, and automatically increases the serial number of changed files zones when restarting the service in BIND.

I also use it in my nfsen server to keep a version of a binary compiled for me, instead of the version of the deb package.

In that way, you can modify the original location to your heart´s content.

I manage too many systems for my liking, so to speak, and to change standard places of file system configurations - so hence using this functionality in some more esoteric configuration where I do not want the modification squashed but still want to benefit from the upgrades.

You might even already have file divertions in place used by Debian by default, just use the following command to list them:

dpkg-divert --list

From man dpkg-divert

EXAMPLES

   To  divert  all  copies  of  a /usr/bin/example to /usr/bin/example.foo, i.e.
   directs  all  packages  providing   /usr/bin/example   to   install   it   as
   /usr/bin/example.foo, performing the rename if required:

   dpkg-divert --divert /usr/bin/example.foo --rename /usr/bin/example

   To remove that diversion:

   dpkg-divert --rename --remove /usr/bin/example

   To    divert    any   package   trying   to   install   /usr/bin/example   to
   /usr/bin/example.foo, except your own wibble package:

   dpkg-divert   --package   wibble   --divert   /usr/bin/example.foo   --rename
          /usr/bin/example

   To remove that diversion:

   dpkg-divert --package wibble --rename --remove /usr/bin/example

See also from the Debian-Administration.org site Replacing binaries with dpkg-divert

Obviously, that whilst the directive is quite useful, I do not recommend abusing it too much.

As for @Stephen Kitt addressing possible problems with configuration files, what happens is that the upgrades will touch the diverted file, and if the configuration has significant changes, for instance, the odds are greater that upgrading to a new Debian version, the daemon won't boot, and that situation has to be addressed manually. Also, to be entirely fair, that can also happen even without having the configuration file diverted.

IMO dkpg-divert is one of the functionalities that shows the true flexibility of the Debian package manager compared to other Linux distributions.

As Stephen said, you have to edit the configuration files directly, but it doesn't mean that you have to put your custom directives there.

Edit /etc/logrotate.d/rsyslog adding at the end of the existing directives, just one line which includes a separate file containing your own override directives:

/var/log/syslog
{
        ... existing directives ...

        include /etc/logrotate.d/override/rsyslog
}

Then create your override file, containing nothing more than your override directives:

/etc/logrotate.d/override/rsyslog

weekly
rotate 0

You still have to pay attention during the system upgrade, but it's really simple to patch back again the default configuration provided by the packages: It's just one line to add.

For me it's an acceptable compromise, since at least it saves me from merging manually the differences on each system upgrade, while keeping my system standards compliant, clear and understandable.