[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: init system policy



On Thu, Nov 20, 2014 at 8:28 AM, Russ Allbery <rra@debian.org> wrote:
> Jonas Smedegaard <dr@jones.dk> writes:
>
>> Seems to me this is a similar limitation as for config.d structures - as
>> an example apache2 is now far more modular than in the past but I no
>> longer as sysadmin get notified what exactly has changed when I upgrade
>> a system with customizations, as I did in the past thanks to the
>> monolithic configfile being a conffile.
>
> There was some discussion about this a while back, and I vaguely remember
> that systemd comes with a tool that will tell you exactly what you're
> overriding.  I'm not sure if that work got all the way to producing a nice
> Debian-aware tool or not.
>
> Personally (and this is just a wishlist), I'd love to have functionality
> similar to apt-listchanges that would (optionally) show me a report of
> every change to any unit file that I've overridden on each upgrade.

But systemd is not the only package to provide a vendor config in /lib
(or /usr/share or /usr/lib) and allow it to be overridden by a file in
/etc. One example is mountall, which provides a base fstab in
/lib/init/ that is overridden by entries in /etc/fstab. networkd and
many other systemd components are similar in this as well. I think
debian conffiles need a generic mechanism that allows packages to
associate files in /etc with files in the vendor directories like /lib
so that the admin is notified when the vendor supplied configuration
is changed. Maybe it could look like this, in
`debian/package.conffiles` :

    # traditional conffiles entries
    /etc/package/main.conf
    # new entries
    # admin-supplied vendor-supplied
    /etc/package/other.conf /usr/share/package/other.conf
    /etc/systemd/system/package.service /lib/systemd/system/package.service
    /etc/systemd/system/package.service.d/* /lib/systemd/system/package.service

Seeing as systemd upstream is pushing the "stateless systems" idea,
and there is definitely merit to it, I think this is the best way to
tackle the issue.

Best wishes,
--
Cameron Norman


Reply to: