Stripping noop configuration file changes from SRUs

Balint Reczey balint.reczey at
Mon Aug 13 13:23:30 UTC 2018

Dear Release Team,

The SRU process description [1]  mentions providing minimal fixes to
solve issues but does not mention handling configuration file changes

I found some cases where SRUs (for example for unattended-upgrades)
listed new default values as comments in the main configuration file.
Upon upgrade this changed configuration file may trigger a question to
the system administrator to accept/merge the changes in case the
configuration file on the system is modified locally. This question
makes  the upgrade a bit more slower and requires more attention.
Also when unattended-upgrades detect locally modified configuration
files it keeps back packages updating those configuration files from
being automatically upgraded potentially leaving security issues not

Stripping SRUs of configuration file changes which do not change the
system's behavior OTOH can make the configuration files less
informative by e.g not listing new configuration options of may be
misleading if a configuration item's default is changed. Those
inaccuracies would be fixed with each release upgrade when the
packages are upgraded to a release which contain the original fixes
which were SRUd.

Even after considering the mentioned downsides I'd like to propose
adopting the policy of stripping configuration file changes from the
SRUs unless they are needed as part of the fix to be back-ported to
make upgrades smoother.


Balint Reczey
Ubuntu & Debian Developer


More information about the Ubuntu-release mailing list