Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)

[William Hubbs]

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.

> 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.