1 |
On Sat, Mar 1, 2014 at 8:06 AM, William Hubbs <williamh@g.o> wrote: |
2 |
|
3 |
> On Sat, Mar 01, 2014 at 06:48:54AM +0000, Steven J. Long wrote: |
4 |
> > On Fri, Feb 28, 2014 at 09:31:08PM -0600, William Hubbs wrote: |
5 |
> > > On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote: |
6 |
> > > > But let's be real here: if I install something and |
7 |
> > > > want to configure its system-wide bits, the first place I go is |
8 |
> ALWAYS |
9 |
> > > > /etc. When I don't find it there, with the rest of the system config |
10 |
> > > > files, my day gets a little worse and I lose a bit of time trying to |
11 |
> > > > interrogate a search engine for the answer. And that's annoying. |
12 |
> > > > That sucks. |
13 |
> > > |
14 |
> > > This hasn't changed. |
15 |
> > > The configuration files these packages are putting in /lib are not |
16 |
> > > meant to be edited; they are the package provided defaults. If you want |
17 |
> > > to override one of them, you do that in a file with the same path and |
18 |
> > > name in /etc, like I mentioned in another message in this thread. |
19 |
> > |
20 |
> > The problem, as has been explained many many times, is that the rest |
21 |
> > of the config is somewhere random on the system. But you knew that, |
22 |
> > right? You were just telling a half-truth, effectively. |
23 |
> |
24 |
> No sir, I was not telling a half-truth. |
25 |
> |
26 |
> If the default configuration is stored in /lib/udev/rules.d for example, |
27 |
> and you can override that default by dropping files of the same name in |
28 |
> /etc/udev/rules.d, I don't see what the concern is. |
29 |
> |
30 |
> |
31 |
My understanding of his point was that right now configs are stored in one |
32 |
file or in one directory. |
33 |
|
34 |
/etc/default/foo perhaps or /etc/foo.d/{a,b,c} |
35 |
|
36 |
it is easy for a some users to determine, using existing tools (vim, less, |
37 |
etc.) to view what the configuration state is. |
38 |
|
39 |
When the default configs are in /lib/udev/.../ and the over-rides are in |
40 |
/etc/udev/.../ that is perhaps less clear. Many applications already |
41 |
provide app specific tools for this. You can run apt-config dump to dump |
42 |
your entire apt configuration (on debian / ubuntu) for example. I'm unsure |
43 |
if polkit or dbus have a tool that will read in the configuration and dump |
44 |
what the daemon thinks the state would be (if it loaded it.) (puppet has |
45 |
|
46 |
I think part of the oddity of this objection is that this move is years old |
47 |
already. |
48 |
|
49 |
gconf, dconf, polkit, dbus, all do stuff like this. I actually find the |
50 |
solution somewhat elegant from my side as a sysadmin. |
51 |
|
52 |
-A |
53 |
|
54 |
|
55 |
> > I for one prefer a distro to do a bit of work and make my life easier, |
56 |
> > since it makes life easier for everyone who uses the distro. Why the |
57 |
> > hell should I care if some bindist can't etc-update? WTF does that |
58 |
> > have to do with Gentoo? |
59 |
> |
60 |
|
61 |
> With this method, you don't need to etc-update, so I would say that in a |
62 |
> way this is easier. Your system-admin-provided files in /etc are not |
63 |
> owned by the packages, just the files in /lib are. |
64 |
> |
65 |
> > If I wanted a shitty distro that didn't bother to do anything at |
66 |
> > all, I'd use LFS. At least they don't pretend, then fall over themselves |
67 |
> > to do a crap load of work rather than admit a mistake; that hey, y'know |
68 |
> > what? Some of those things from 30 years ago were a damn good idea, |
69 |
> > and maybe just maybe, they worked some of these issues out back then, |
70 |
> > so we could stand on their shoulders instead of digging through |
71 |
> > their garbage. |
72 |
> |
73 |
> I'm not totally against keeping things from the past. It is just a case |
74 |
> of evaluating those things and seeing whether they are still relevant. |
75 |
> |
76 |
> |