| 1 |
On Mon, Dec 7, 2015 at 8:02 PM, Stroller <stroller@××××××××××××××××××.uk> wrote: |
| 2 |
> |
| 3 |
> That's like telling your grandma, "you don't know what DNS is? this is internet 101 - you use DNS all the time". |
| 4 |
> |
| 5 |
> I have not needed to add directories to CONFIG_PROTECT, or alter it in any way, in over 10 years of using Gentoo. |
| 6 |
> |
| 7 |
|
| 8 |
Fair enough, neither have I. I just meant that configruation |
| 9 |
protection itself is a fairly standard and well-used capability. I |
| 10 |
get that somebody might not recognize the name for it or the meaning |
| 11 |
of the environment variable. |
| 12 |
|
| 13 |
> |
| 14 |
> Excuse me. I thought this was a standard thing, just as I have scripts in /usr/local/bin/ and a local Portage tree in /usr/local/portage/, I would have assumed that an application like X11 that looks in /usr/share/X11/ for its configuration files would then look in /usr/share/local/X11/ for any custom symbols or overrides. |
| 15 |
|
| 16 |
No worries. That actually isn't "standard" at all. Most applications |
| 17 |
completely ignore /usr/local, and arguably this should be their |
| 18 |
behavior (the purpose of /usr/local is to install your own stuff, not |
| 19 |
extent stuff in /usr). |
| 20 |
|
| 21 |
The older convention is to stick stuff that is likely to be configured |
| 22 |
in /etc. The newer convention is to stick default config files |
| 23 |
somewhare in /usr and then allow them to be extended or overridden |
| 24 |
using files in /etc (which is how other distros are solving the |
| 25 |
problem that Gentoo solves with configuration protection). |
| 26 |
|
| 27 |
In fact, portage ignores /usr/local/portage by default. You have to |
| 28 |
set a variable or point a repository at it. |
| 29 |
|
| 30 |
|
| 31 |
> |
| 32 |
> I find a couple of approaches to local customisations which keep the files in the user's homedir. |
| 33 |
> |
| 34 |
|
| 35 |
Yeah, that is also a less-common approach. I guess it is more common |
| 36 |
for desktop-y stuff. |
| 37 |
|
| 38 |
> I believe strongly in that kind of separation between _system files that the user has customised_ and _original system files which will be updated and maintained by the package manager_. However it's not clear that it's so clean and tidy with X11, and I can certainly see there's a good argument for CONFIG_PROTECT. |
| 39 |
|
| 40 |
Agree. And I don't disagree with the earlier solution to use a |
| 41 |
configuration management solution. One of my projects for a really |
| 42 |
dull weekend is to get around to Ansible-izing all my containers. |
| 43 |
Granted, containers are really easy to snapshot and manage even |
| 44 |
without this, but it is an excuse to learn Ansible anyway. |
| 45 |
|
| 46 |
-- |
| 47 |
Rich |
Archives