Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 194665 - x11-misc/xkeyboard-config - /usr/share/X11/xkb should not be CONFIG_PROTECTed
Summary: x11-misc/xkeyboard-config - /usr/share/X11/xkb should not be CONFIG_PROTECTed
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: x86 Linux
: High minor (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-04 01:36 UTC by Christian Schnarr
Modified: 2010-08-21 21:00 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Schnarr 2007-10-04 01:36:13 UTC
I did an world update...
...and 96 files to xkb seem a little bit too much...
...or do I really have to deal with it on the ordinary way?
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2007-10-04 07:20:59 UTC
Yes, you really have to; you can stick /usr/share/X11/xkb to CONFIG_PROTECT_MASK  or set replace-unmodified=yes in /etc/dispatch-conf.conf and use dispatch-conf instead of etc-update if you hate this.

That said, I still don't see why are we forcing this on users, if someone insist on modifying the default keymaps, then should CONFIG_PROTECT them themselves, instead of this cruft being forced on users by default when the vast majority of users never touches those.
Comment 2 Donnie Berkholz (RETIRED) gentoo-dev 2007-10-05 06:54:23 UTC
I've already changed that in xkeyboard-config 1.1, actually. But files 
in /etc/ stick around till you get rid of them. Delete the one in 
/etc/env.d/ that has /usr/share/X11/xkb in it.
Comment 3 Donnie Berkholz (RETIRED) gentoo-dev 2007-10-05 06:54:57 UTC
For that reason, considering fixed.
Comment 4 Léo 2010-08-21 20:45:06 UTC
It was brought back in xkeyboard-config-1.7.ebuild when it was created. The CVS log says "bump to 1.7, sync with x11 overlay", and indeed the two lines come from the X11 overlay ebuild.

Version 1.9 was recently stabilized, and there is 80 files in /usr/share/X11/xkb which need updating.

If there is still no reason for it, thanks to remove it again (and I guess it should be removed from the overlay too...).

As it was said, the workaround is to add /usr/share/X11/xkb to CONFIG_PROTECT_MASK (in /etc/make.conf) before emerging it, or setting replace-unmodified=yes in /etc/dispatch-conf.conf if already emerged and before running `dispatch-conf` (if you don't want to replace unmodified files in other directories, run `CONFIG_PROTECT="/usr/share/X11/xkb" dispatch-conf` instead, and then set replace-unmodified back to no).

Thanks to everyone who will work on this.
Comment 5 Léo 2010-08-21 21:00:24 UTC
(In reply to comment #4)
> As it was said, the workaround is to add /usr/share/X11/xkb to
> CONFIG_PROTECT_MASK (in /etc/make.conf) before emerging it, or setting
> replace-unmodified=yes in /etc/dispatch-conf.conf if already emerged and 
> before running `dispatch-conf` (if you don't want to replace unmodified
> files in other directories, run `CONFIG_PROTECT="/usr/share/X11/xkb"
> dispatch-conf` instead, and then set replace-unmodified back to no).

Sorry about the double reply, but apparently replace-unmodified=yes is in fact not useful here, if you have not already updated the files in /usr/share/X11/xkb so dispatch-conf knows about them. So just run `CONFIG_PROTECT="/usr/share/X11/xkb" dispatch-conf` and spam "u" (with "q" before it, if the patch is too long and is being scrolled through).