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

Re: sysadmin configuration of sparse-/etc vs prepopulated-/etc?

>>>>> "Josh" == Josh Triplett <josh@joshtriplett.org> writes:

    Josh> If we're talking about developing a solution that doesn't
    Josh> already exist, why not have that solution *be* the
    Josh> notification-and-diff/show-the-defaults mechanism you're
    Josh> describing? For instance, provide a declarative mechanism to
    Josh> say "this file/directory in /usr is the default version of
    Josh> this configuration file in /etc", with standard schemes like
    Josh> 'merge' or 'override'", and then offer a tool (similar to the
    Josh> existing systemd-delta but generalized) to show all the
    Josh> configuration files that differ, as well as automatic support
    Josh> for flagging changes on upgrades and suggesting a three-way
    Josh> merge (similar to ucf)? With some care for
    Josh> convention-over-configuration, debhelper could auto-populate
    Josh> this declarative data in many cases.

Yeah, I was thinking about something like this.  But I think details
about where the vendor config lives should be part of the design work.
I.E.  we could accomplish roughly the same thing by taking the files
that packages populate into /etc as the vendor config and still meet the
standard unix assumptions of a populated /etc.

There are trade offs.  If you come from the place of believing that
supporting empty /etc is valuable, then what you propose is an obvious
way forward.
If you have not accepted that value proposition, I think you may be
closing off design space by going that route.

Like Steve, I do not want to drive the discussion, but like Steve, I do
think the discussion needs to happen.
I strongly encourage those who value empty /etc to drive such a
discussion and to explain to the project why we want that.


Reply to: