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.
--Sam
Reply to: