Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Mick]

On Tuesday 08 Dec 2015 03:29:45 Rich Freeman wrote:
> On Mon, Dec 7, 2015 at 8:02 PM, Stroller  
wrote:
> > That's like telling your grandma, "you don't know what DNS is? this is
> > internet 101 - you use DNS all the time".
> > 
> > I have not needed to add directories to CONFIG_PROTECT, or alter it in
> > any way, in over 10 years of using Gentoo.
> 
> Fair enough, neither have I.  I just meant that configruation
> protection itself is a fairly standard and well-used capability.  I
> get that somebody might not recognize the name for it or the meaning
> of the environment variable.

Actually, I recall that pre-2003/04 we used to edit the list of protected 
directories.  I think that the reason at the time was that etc-update would 
take too long to scan all of them, so the user was encourage to limit these 
according to preference.

There may be some old threads lurking around the M/L archives on this topic.
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Stroller]

> On Sun, 6 December 2015, at 6:49 p.m., Rich Freeman  wrote:
> 
> If somebody has a link to the docs for this please post it, as it
> seems like this has disappeared from the handbook.  This used to be
> Gentoo 101…

That seems like a somewhat dubious statement, if it wasn't just intended to be 
an insult.

I've been using Gentoo for over a decade - since before you were a developer, 
at least.

Stroller.

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Rich Freeman]

On Mon, Dec 7, 2015 at 3:40 PM, Stroller  wrote:
>
>> On Sun, 6 December 2015, at 6:49 p.m., Rich Freeman  wrote:
>>
>> If somebody has a link to the docs for this please post it, as it
>> seems like this has disappeared from the handbook.  This used to be
>> Gentoo 101…
>
> That seems like a somewhat dubious statement, if it wasn't just intended to 
> be an insult.
>

It wasn't really targeted at anybody in particular.  It just should be
clear in the documentation since config protection and merging config
changes is a big part of administering a Gentoo system.  It probably
should be in the handbook, and it looks like it was at some time in
the past.

Config protection isn't some exotic feature that few use (like
crossdev, prefix, hardened, or glentoo).  It is pretty central to the
whole design of portage, and I believe all the other package managers
implement it as well in some form.

> I've been using Gentoo for over a decade - since before you were a developer, 
> at least.
>

Glad to hear I'm not the only one who ran it in the Pentium3 over a
modem days who is still around.  :)

-- 
Rich

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Stroller]

> On Mon, 7 December 2015, at 9:24 p.m., Rich Freeman  wrote:
> 
> It wasn't really targeted at anybody in particular.  It just should be
> clear in the documentation since config protection and merging config
> changes is a big part of administering a Gentoo system.  It probably
> should be in the handbook, and it looks like it was at some time in
> the past.
> 
> Config protection isn't some exotic feature that few use (like
> crossdev, prefix, hardened, or glentoo).  It is pretty central to the
> whole design of portage, and I believe all the other package managers
> implement it as well in some form.

It seems just a tad exotic to me, as I haven't used or needed it in over 10 
years.

Am I not correct in thinking that a /usr/local/whatever directory would work as 
I described previously? [1]

>> I've been using Gentoo for over a decade - since before you were a 
>> developer, at least.
> 
> Glad to hear I'm not the only one who ran it in the Pentium3 over a
> modem days who is still around.  :)

I still have a Pentium 3 running here. Embarrassingly, it hasn't been updated 
since the hard drive was in a Pentium 2.

$ cat /etc/*rele*
Gentoo Base System version 1.4.16
$ 

Stroller.


[1] http://article.gmane.org/gmane.linux.gentoo.user/287491

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Rich Freeman]

On Mon, Dec 7, 2015 at 6:16 PM, Stroller  wrote:
>
>> On Mon, 7 December 2015, at 9:24 p.m., Rich Freeman  wrote:
>>
>> It wasn't really targeted at anybody in particular.  It just should be
>> clear in the documentation since config protection and merging config
>> changes is a big part of administering a Gentoo system.  It probably
>> should be in the handbook, and it looks like it was at some time in
>> the past.
>>
>> Config protection isn't some exotic feature that few use (like
>> crossdev, prefix, hardened, or glentoo).  It is pretty central to the
>> whole design of portage, and I believe all the other package managers
>> implement it as well in some form.
>
> It seems just a tad exotic to me, as I haven't used or needed it in over 10 
> years.
>

You never run etc-update or dispatch-conf?  If you do, you're using
it.  You're just using its default configuration and not adding
directories to it.

> Am I not correct in thinking that a /usr/local/whatever directory would work 
> as I described previously? [1]
>

Only if you patch the program in question to read the file there.  And
if you're going to go to all that trouble you should really patch it
to allow the file to be overridden in /etc which is the more current
tradition.  And if you're going to do that you might as well just
patch the program to install the file the way you want it in the first
place.


-- 
Rich

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Rich Freeman]

On Mon, Dec 7, 2015 at 8:02 PM, Stroller  wrote:
>
> That's like telling your grandma, "you don't know what DNS is? this is 
> internet 101 - you use DNS all the time".
>
> I have not needed to add directories to CONFIG_PROTECT, or alter it in any 
> way, in over 10 years of using Gentoo.
>

Fair enough, neither have I.  I just meant that configruation
protection itself is a fairly standard and well-used capability.  I
get that somebody might not recognize the name for it or the meaning
of the environment variable.

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

No worries.  That actually isn't "standard" at all.  Most applications
completely ignore /usr/local, and arguably this should be their
behavior (the purpose of /usr/local is to install your own stuff, not
extent stuff in /usr).

The older convention is to stick stuff that is likely to be configured
in /etc.  The newer convention is to stick default config files
somewhare in /usr and then allow them to be extended or overridden
using files in /etc (which is how other distros are solving the
problem that Gentoo solves with configuration protection).

In fact, portage ignores /usr/local/portage by default.  You have to
set a variable or point a repository at it.


>
> I find a couple of approaches to local customisations which keep the files in 
> the user's homedir.
>

Yeah, that is also a less-common approach.  I guess it is more common
for desktop-y stuff.

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

Agree.  And I don't disagree with the earlier solution to use a
configuration management solution.  One of my projects for a really
dull weekend is to get around to Ansible-izing all my containers.
Granted, containers are really easy to snapshot and manage even
without this, but it is an excuse to learn Ansible anyway.

-- 
Rich

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Stroller]

> On Tue, 8 December 2015, at 12:29 a.m., Rich Freeman  wrote:
>> 
>> It seems just a tad exotic to me, as I haven't used or needed it in over 10 
>> years.
> 
> You never run etc-update or dispatch-conf?  If you do, you're using
> it.  You're just using its default configuration and not adding
> directories to it.

That's like telling your grandma, "you don't know what DNS is? this is internet 
101 - you use DNS all the time".

I have not needed to add directories to CONFIG_PROTECT, or alter it in any way, 
in over 10 years of using Gentoo.


>> Am I not correct in thinking that a /usr/local/whatever directory would work 
>> as I described previously? [1]
> 
> Only if you patch the program in question to read the file there.

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.

I find a couple of approaches to local customisations which keep the files in 
the user's homedir.

• https://wiki.archlinux.org/index.php/X_KeyBoard_extension#Local_XKB_folder
• http://www.vinc17.org/unix/xkb.en.html

My instinct is to prefer keeping them there, because it should mean that the 
user can copy his homedir to a new system or distro (or have it propagated over 
NFS or by a roaming profile) and his customisation(s) will still work (or, at 
least, the user will have copies of the config files which they can more easily 
install).

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.

Stroller.

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Stroller]

> On Fri, 4 December 2015, at 12:55 p.m., Rich Freeman  wrote:
>> 
>> Surely it should go in somewhere like /usr/local/share/X11/xkb/symbols/ 
>> instead.
>> 
>> Making the original /usr/share/X11/xkb/symbols/ directory read-only prevents 
>> updates and bug fixes being applied.
>> 
> 
> Nobody suggested making the directory read-only.  They suggested
> adding it to CONFIG_PROTECT in make.conf, which treats the directory
> the same as /etc with the need to merge changes.  

Ok, so you're saying that putting the CONFIG_PROTECT in make.conf, makes the 
directory read-only only for portage, right?

If you want to be precise, it tells portage not to write there, I think.

Whichever way you want to spell it, doesn't this prevent updates and bug fixes 
from being applied?

Stroller.

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Stroller]

> On Fri, 4 December 2015, at 4:13 p.m., gevisz  wrote:
>> 
>> Surely it should go in somewhere like /usr/local/share/X11/xkb/symbols/ 
>> instead.
> 
> I do not have /usr/local/share directory at all. Do you think it is wrong?

Local directories are ones which you can create to put system stuff in, system 
stuff which isn't supplied by the distro.

The package manager won't install into local directories, so your changes won't 
be overwritten.

Use of a directory like /usr/local/share/X11/xkb/symbols/ would require X11 to 
honour that path - you'd need to check.

Stroller.

* 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-filesystem-fhs.html
• 
http://unix.stackexchange.com/questions/11544/what-is-the-difference-between-opt-and-usr-local
• 
https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s3-filesystem-usr-local.html
• http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Rich Freeman]

On Sun, Dec 6, 2015 at 12:44 PM, Stroller
 wrote:
>
>> On Fri, 4 December 2015, at 12:55 p.m., Rich Freeman  
>> wrote:
>>>
>>> Surely it should go in somewhere like /usr/local/share/X11/xkb/symbols/ 
>>> instead.
>>>
>>> Making the original /usr/share/X11/xkb/symbols/ directory read-only 
>>> prevents updates and bug fixes being applied.
>>>
>>
>> Nobody suggested making the directory read-only.  They suggested
>> adding it to CONFIG_PROTECT in make.conf, which treats the directory
>> the same as /etc with the need to merge changes.
>
> Ok, so you're saying that putting the CONFIG_PROTECT in make.conf, makes the 
> directory read-only only for portage, right?
>
> If you want to be precise, it tells portage not to write there, I think.
>
> Whichever way you want to spell it, doesn't this prevent updates and bug 
> fixes from being applied?

Nope.  It just enabled configuration protection, as is the default for /etc.

So changes go into new files, and then you can merge them with
dispatch-conf or cfg-update or whatever your favorite tool for merging
config file changes is.

If somebody has a link to the docs for this please post it, as it
seems like this has disappeared from the handbook.  This used to be
Gentoo 101...

-- 
Rich

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Neil Bothwick]

On Sun, 6 Dec 2015 13:49:15 -0500, Rich Freeman wrote:

> > Ok, so you're saying that putting the CONFIG_PROTECT in make.conf,
> > makes the directory read-only only for portage, right?

> Nope.  It just enabled configuration protection, as is the default
> for /etc.
> 
> So changes go into new files, and then you can merge them with
> dispatch-conf or cfg-update or whatever your favorite tool for merging
> config file changes is.
> 
> If somebody has a link to the docs for this please post it, as it
> seems like this has disappeared from the handbook.  This used to be
> Gentoo 101...

man emerge - the section on configuration files.

Yes, it was a bit of a treasure hunt finding that, it was mentioned in
man make.conf but nothing about it in man portage :(


-- 
Neil Bothwick

Despite the cost of living, have you noticed how it remains so popular?


pgpr3qrvD7306.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Peter Humphrey]

On Friday 04 December 2015 13:55:30 gevisz wrote:

> So, my main question is How can I ensure that the already
> edited /usr/share/X11/xkb/symbols/ru file will not be overwritten
> during the next system update.

Add it to CONFIG_PROTECT in make.conf.

-- 
Rgds
Peter

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[gevisz]

2015-12-04 14:10 GMT+02:00 Peter Humphrey :
> On Friday 04 December 2015 13:55:30 gevisz wrote:
>
>> So, my main question is How can I ensure that the already
>> edited /usr/share/X11/xkb/symbols/ru file will not be overwritten
>> during the next system update.
>
> Add it to CONFIG_PROTECT in make.conf.

Done. Thank you and all the others who replied to this question.

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Stroller]

> On Fri, 4 December 2015, at 12:10 p.m., Peter Humphrey 
>  wrote:
> 
> On Friday 04 December 2015 13:55:30 gevisz wrote:
> 
>> So, my main question is How can I ensure that the already
>> edited /usr/share/X11/xkb/symbols/ru file will not be overwritten
>> during the next system update.
> 
> Add it to CONFIG_PROTECT in make.conf.

Surely it should go in somewhere like /usr/local/share/X11/xkb/symbols/ instead.

Making the original /usr/share/X11/xkb/symbols/ directory read-only prevents 
updates and bug fixes being applied.

Stroller.

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Rich Freeman]

On Fri, Dec 4, 2015 at 7:38 AM, Stroller  wrote:
>
>> On Fri, 4 December 2015, at 12:10 p.m., Peter Humphrey 
>>  wrote:
>>
>> On Friday 04 December 2015 13:55:30 gevisz wrote:
>>
>>> So, my main question is How can I ensure that the already
>>> edited /usr/share/X11/xkb/symbols/ru file will not be overwritten
>>> during the next system update.
>>
>> Add it to CONFIG_PROTECT in make.conf.
>
> Surely it should go in somewhere like /usr/local/share/X11/xkb/symbols/ 
> instead.
>
> Making the original /usr/share/X11/xkb/symbols/ directory read-only prevents 
> updates and bug fixes being applied.
>

Nobody suggested making the directory read-only.  They suggested
adding it to CONFIG_PROTECT in make.conf, which treats the directory
the same as /etc with the need to merge changes.  That is probably the
simplest solution here, as others would require ebuild changes,
patching, or getting upstream to allow the file to be overridden in
/etc (assuming this is not already possible).

-- 
Rich

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Alec Ten Harmsel]

On Fri, Dec 04, 2015 at 01:55:30PM +0200, gevisz wrote:
> 
> So, my main question is How can I ensure that the already
> edited /usr/share/X11/xkb/symbols/ru file will not be overwritten
> during the next system update. Thabk you.
> 

Use a configuration management tool like puppet or ansible. It will take
a small amount of initial investment to set up, but then any overwritten
configuration files can be easily added back by running the
configuration management tool.

Alec

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[Peter Humphrey]

On Friday 04 December 2015 12:38:16 Stroller wrote:
> > On Fri, 4 December 2015, at 12:10 p.m., Peter Humphrey
> >  wrote:> 
> > On Friday 04 December 2015 13:55:30 gevisz wrote:
> >> So, my main question is How can I ensure that the already
> >> edited /usr/share/X11/xkb/symbols/ru file will not be overwritten
> >> during the next system update.
> > 
> > Add it to CONFIG_PROTECT in make.conf.
> 
> Surely it should go in somewhere like /usr/local/share/X11/xkb/symbols/
> instead.

What should go there?

> Making the original /usr/share/X11/xkb/symbols/ directory read-only
> prevents updates and bug fixes being applied.

I don't understand. No-one suggested read-only directories. We seem to be at 
cross-purposes.

-- 
Rgds
Peter

Re: [gentoo-user] preventing keyboard layout files from being overritten during system upgrades

[gevisz]

2015-12-04 14:38 GMT+02:00 Stroller :
>
>> On Fri, 4 December 2015, at 12:10 p.m., Peter Humphrey 
>>  wrote:
>>
>> On Friday 04 December 2015 13:55:30 gevisz wrote:
>>
>>> So, my main question is How can I ensure that the already
>>> edited /usr/share/X11/xkb/symbols/ru file will not be overwritten
>>> during the next system update.
>>
>> Add it to CONFIG_PROTECT in make.conf.
>
> Surely it should go in somewhere like /usr/local/share/X11/xkb/symbols/ 
> instead.

I do not have /usr/local/share directory at all. Do you think it is wrong?