On Sat, Mar 1, 2014 at 8:06 AM, William Hubbs <willi...@gentoo.org> wrote:

> On Sat, Mar 01, 2014 at 06:48:54AM +0000, Steven J. Long wrote:
> > On Fri, Feb 28, 2014 at 09:31:08PM -0600, William Hubbs wrote:
> > > On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote:
> > > > But let's be real here: if I install something and
> > > > want to configure its system-wide bits, the first place I go is
> ALWAYS
> > > > /etc.  When I don't find it there, with the rest of the system config
> > > > files, my day gets a little worse and I lose a bit of time trying to
> > > > interrogate a search engine for the answer.  And that's annoying.
> > > > That sucks.
> > >
> > > This hasn't changed.
> > > The configuration files these packages are putting in /lib are not
> > > meant to be edited; they are the package provided defaults. If you want
> > > to override one of them, you do that in a file with the same path and
> > > name in /etc, like I mentioned in another message in this thread.
> >
> > The problem, as has been explained many many times, is that the rest
> > of the config is somewhere random on the system. But you knew that,
> > right? You were just telling a half-truth, effectively.
>
> No sir, I was not telling a half-truth.
>
> If the default configuration is stored in /lib/udev/rules.d for example,
> and you can override that default by dropping files of the same name in
> /etc/udev/rules.d, I don't see what the concern is.
>
>
My understanding of his point was that right now configs are stored in one
file or in one directory.

/etc/default/foo perhaps or /etc/foo.d/{a,b,c}

it is easy for a some users to determine, using existing tools (vim, less,
etc.) to view what the configuration state is.

When the default configs are in /lib/udev/.../ and the over-rides are in
/etc/udev/.../ that is perhaps less clear. Many applications already
provide app specific tools for this. You can run apt-config dump to dump
your entire apt configuration (on debian / ubuntu) for example. I'm unsure
if polkit or dbus have a tool that will read in the configuration and dump
what the daemon thinks the state would be (if it loaded it.) (puppet has

I think part of the oddity of this objection is that this move is years old
already.

gconf, dconf, polkit, dbus, all do stuff like this. I actually find the
solution somewhat elegant from my side as a sysadmin.

-A


> > I for one prefer a distro to do a bit of work and make my life easier,
> > since it makes life easier for everyone who uses the distro. Why the
> > hell should I care if some bindist can't etc-update? WTF does that
> > have to do with Gentoo?
>

> With this method, you don't need to etc-update, so I would say that in a
> way this is easier. Your system-admin-provided files in /etc are not
> owned by the packages, just the files in /lib are.
>
> > If I wanted a shitty distro that didn't bother to do anything at
> > all, I'd use LFS. At least they don't pretend, then fall over themselves
> > to do a crap load of work rather than admit a mistake; that hey, y'know
> > what? Some of those things from 30 years ago were a damn good idea,
> > and maybe just maybe, they worked some of these issues out back then,
> > so we could stand on their shoulders instead of digging through
> > their garbage.
>
>  I'm not totally against keeping things from the past. It is just a case
>  of evaluating those things and seeing whether they are still relevant.
>
>

Reply via email to