Summary: | kde-misc/polkit-kde-kcmodules: Store polkit configuration changes to /etc instead of /usr | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nikoli <nikoli> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | creffett, eugene.shalygin, freedesktop-bugs, kripton, virtuousfox |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
http://bugs.gentoo.org/show_bug.cgi?id=415583 http://bugs.kde.org/show_bug.cgi?id=308934 https://bugs.gentoo.org/show_bug.cgi?id=480898 |
||
Whiteboard: | removed on 2013/12/30 | ||
Package list: | Runtime testing required: | --- |
Description
Nikoli
2012-10-18 12:34:22 UTC
You shouldn't be editing anything in /usr directly but override the settings in /etc if needed. Namely JS based .rules files as described by 'man polkitd' in /etc/polkit-1/rules.d/ So no, we won't protect anything polkit/dbus/etc. related in /usr *** This bug has been marked as a duplicate of bug 415583 *** I do not edit this files with text editor. I changed security settings with KDE tool and tool saved files in /usr instead of /etc. This is the main reason why kde herd is subscribed. systemsettings is not asking where to safe files. endeed, try telling that to KDE guys, Gentoo-devs. they even store KDM settings under /usr (but you surely familiar with whole /usr/share/config). and what the hell users supposed to do about it ? Then the configuration system from KDE is flawed and needs to be fixed to write proper JS .rules files to correct location, the /etc, as per polkit design Note that /usr is designed so that it can be mounted as ro (read only) and polkit has always been designed to allow it, since the old "PolicyKit" times If this needs upstream code (patch) then I'd suggest to not ship the faulty KCM module for now, or keep it strictly overlay based as non-supported indeed it's flawed (no data should be in /usr, which is changeable by users & processes over than package manager), but this is what we have: a major DE with this kind of design decision. as a user, i hesitant to even bring it up to the upstream, as they don't take design criticism from "vocal minority" well. therefore, i suggest something like making a more official pleading to them from willing Gentoo-devs about it. Futhermore this explains why Gentoo users are struggling with polkit rules problems (many posts in forums and also open bugs in bugzilla) since editing the files in /usr makes the whole thing undebuggable mess I'll need to make it a standard practise to close any polkit bugs with this KCM module installed as invalid :-/ kde-misc/polkit-kde-kcmodules is a direct dependency of kde-base/kdelibs and, therefore, of whole KDE. this is how KDE officially deals with PolKit, as i gathered. so, maybe ignoring that 'undebuggable mess' as a "standard practise" would be not such a good idea either. it will not go away by itself any time soon. Not a regression, so does not block stabilisation. The paths are hard-coded, so I am not really sure what we can do downstream. (In reply to comment #11) > The paths are hard-coded, so I am not really sure what we can do downstream. Removing the package from gentoo-x86 would be a start. This is quite serious bug. To emphatize this more: The package is writing to *static files that should _never_ be edited in /usr beloging to other package* Once removed from gentoo-x86, I'll add blockers on it in polkit ebuilds. (In reply to comment #11) > The paths are hard-coded, so I am not really sure what we can do downstream. as i said, you can communicate to the upstream, that this (putting/editing configs in /usr) is _not OK_. (In reply to comment #12) > (In reply to comment #11) > > The paths are hard-coded, so I am not really sure what we can do downstream. > > Removing the package from gentoo-x86 would be a start. This is quite serious > bug. are you going to remove entire KDE ? because this is what the core of it does, now it's just extends to a non-KDE configs (which _is_ insane, as insane as ripping polkit support entirely from it. are you even sure that KDE be fully-functional after that ?), you can't sweep it under the rug like that. this is not a accidental mistake, this is a design, it will not go away and make things nice and maintainable after a while by itself. if you really want to do something useful by yourself and fast, i'd suggest like developing a patch, that makes it use proper paths. (In reply to comment #14) > as i said, you can communicate to the upstream, that this (putting/editing > configs in /usr) is _not OK_. Links to upstream bugreports welcome. > if you really want to do something useful by yourself and fast, i'd suggest > like developing a patch, that makes it use proper paths. Patches also welcome. blocking and breaking a major DE instead of doing anything useful is not welcome, on the other hand. personally, i'm done debating with either KDE-devs or you. maybe you'll manage to painlessly remove kde-misc/polkit-kde-kcmodules from kdelibs's deps, maybe you'll not. but, hopefully, if anyone screws up my desktop too much, there're always alternatives. i just pity the ones, for whom that might come as a surprise on updating. Bug filed upstream, let the flame wars begin. Okay, quick summary of the upstream discussion: 1. Most places don't ship polkit-kde-kcmmodules (they're not officially recommended for general usage) 2. kdm has a similar deal with editing /usr settings, several distros (Fedora, Slackware) just symlink /usr/share/config/kdm to /etc/kde/kdm. 3. Debian patches to make /etc/kde4 the config directory for KDE. 4. Fedora also patches to make four settings for config locations: in ~, in /etc/ in /usr for fedora-shipped settings, and in /usr for upstream-shipped settings. 5. KDE Frameworks 5 will allow us to export XDG_CONFIG_DIRS for system-wide changes and XDG_CONFIG_HOME (defaulting to ~/.config), obviating the need for patches. As things stand, I think it would be a bad idea to attempt to make these changes in the 4.9 timeframe, it's too soon. Kensington and I will look at implementing a fix when 4.10 is released, and I will bring this up at the next KDE team meeting so we can pick one of the options to implement. I don't object adding [ ... VERY quick snip of code ... ] src_install() { local envdfn=99polkit-kde echo 'CONFIG_PROTECT_MASK="/usr/share/polkit-1/actions"' > "${T}"/${envdfn} doenvd "${T}"/${envdfn} } [ ... end snip of code ] to kde-misc/polkit-kde-kcmodules instead of the initial suggestion of adding it to polkit -- because the bug is not in polkit-1 and there is no reason why Xfce users, for example, should deal with stuff they shouldn't be dealing with that's for meanwhile since upstream has now been contacted and there looks to be a plan according to Comment #18 (just saying with my polkit hat on that you can do that because KDE as a major desktop deserves an exception, even if it's bit off what is wanted. anyway you want, you have veto here too.) Do we want to ship Samuli's suggestion in comment #19 with 4.9.3, or wait until 4.10 with a better fix? I am fine with adding that for now to sort these issues out fast, then we fix it right in 4.10. (In reply to comment #19) > src_install() { > local envdfn=99polkit-kde > echo 'CONFIG_PROTECT_MASK="/usr/share/polkit-1/actions"' > "${T}"/${envdfn} > doenvd "${T}"/${envdfn} > } CONFIG_PROTECT or CONFIG_PROTECT_MASK? (In reply to comment #22) > (In reply to comment #19) > > src_install() { > > local envdfn=99polkit-kde > > echo 'CONFIG_PROTECT_MASK="/usr/share/polkit-1/actions"' > "${T}"/${envdfn} > > doenvd "${T}"/${envdfn} > > } > > CONFIG_PROTECT or CONFIG_PROTECT_MASK? CONFIG_PROTECT, sorry that _MASK was a mistake (typo or brainfreeze :) I've revision-bumped the package and added the CONFIG_PROTECT bit, will request a stable on that soon since it's a fairly minor change. Kensington and I will start looking into the options we've seen for a permanent fix now that KDE 4.10 beta 1 is out, and experiment with it there. S(In reply to comment #24) > I've revision-bumped the package and added the CONFIG_PROTECT bit, will > request a stable on that soon since it's a fairly minor change. Stabilisation will occur along with KDE-4.10.1 I've been waiting for this to get lastrited... And now I see people talking of stabilizing it... Please :-( (In reply to comment #26) > I've been waiting for this to get lastrited... And now I see people talking > of stabilizing it... Please :-( The package was already stable, we are just stabilising a revision bump to stop the automatic overwriting. It is still a work-in-progress to get this fixed properly upstream. After discussion in the KDE team meeting, we've decided to remove the package rather than patch it. The dep on polkit-kde-kcmodules has been removed in 4.10.4 and all live versions in the KDE overlay. This leaves users with the package until it is depcleaned, but since the biggest problem has been with configuration files being overwritten on upgrade, I consider this acceptable. Once 4.10.4 or 4.10.5 is stablized, we will mask polkit-kde-kcmodules for lastrite and move it back to the KDE overlay, with the hope that eventually the upstream bug will be fixed and it might be suitable for inclusion in the tree again. Removal announced on -dev and -dev-announce mailing lists. Package removed from tree. |