conffile changes in SRUs

[Emmet Hikory]

Robie Basak wrote:
> But there seems to be some doubt on whether SRUs can change conffiles,
> so I think it would be helpful to clarify this here first.
> 
> Are conffile changes allowed in SRUs? And if not, how should I approach
> fixing this issue?

    While I'm not authoritative, I have trouble believing that we should
say that any specific kind of change should not happen in an SRU: there
are surely many cases where the best way to solve any issue in production
systems may fall into some category we might otherwise have decreed as
unsuitable for some class of update.

    That said, in the specific class of configuration files (whether
conffiles or not), special care must be taken, as we have significantly
less grounds for the expectation that the files in use in production
match those shipped by our packages, and so must take greater care to
ensure a safe update, as it is fairly easy to generate an update that
can cause issues in production (in the specific issue of my.cnf, imagine
the case where a user affected by the issue described has created
/etc/mysql/conf.d/99local-fix-logging).

    Depending on the nature of configuration parsing for the package
concerned, it may be safer to modify the code to provide safe defaults
for missing configuration entries.  If one updates a conffile, one is
asking the user to manage merging any local configuration changes, and
in the case of many of our conffiles, assuming that all supplementary
included configuration is compatible with the change made.  If one
instead modifies the configuration in a postinst, one may affect future
upgrades, perhaps unfortunately in cases where the user has not made
any local configuration changes.  If one imitates full configuration
parsing in a postinst, with the intent of providing a safe configuration
change, either with a new file or preserving user variations in a safe
manner, one might be confident in the safety of the change, but this may
require significant effort, and involve a higher degree of changes to
the package as a whole than setting defaults in the code directly.

    In summary, I'd suggest avoiding changes in conffiles in SRUs if
at all possible: the risk of exposing other issues, or punishing those
users who have the interest and ability to identify the issues is very
high, and the potential benefit as compared to other potential means of
addressing the majority of issues that could be addressed by configuration
changes is fairly low.  Despite this, we should not exclude these from
the potential of an SRU update by policy, for fear of creating a precedent
that prevents us entirely from addressing some future issue.

-- 
Emmet HIKORY