Theo Chatzimichos posted on Fri, 25 Feb 2011 10:38:06 +0200 as excerpted:
> On Fri, Feb 25, 2011 at 10:17 AM, Andreas K. Huettel
> <dilfridge@gentoo.org> wrote:
>>
>> Dear all,
>>
>> at the last kde meeting we've been discussing the usefulness of the use
>> flags consolekit and policykit. I'm quoting from the summary:
>>
>>> scarabeus and dilfridge are in favour of dropping them, since it
>>> caused a lot of trouble debugging various user reports. reavertm
>>> prefers adding it to IUSE defaults. No consensus was succeeded, the
>>> topic will be continued in the gentoo-desktop mailing list.
>>
>> As an example, according to https://bugs.kde.org/show_bug.cgi?id=244444
>> policykit is _not_ a hard dependency of kde, but _required_ whenever
>> you want to "run as" or configure something in systemsettings as root.
>>
>> The three options available are 1) removing the useflags, effectively
>> "forcing them on". Easiest for us maintainers,
>> 2) forcing them on with use.force in the profile, and trust that not so
>> many users figure out how to get around this :)
>> 3) making them "on by default"
>>
>> As a special gem, after switching one of the flags it may be necessary
>> to recompile larger parts of kde and / or restart kdm.
>>
>> Opinions?
>
> The depedencies are indeed really small, but the reason that some of us
> objected is that we want to follow upstream's decisions on what is
> optional and what is not. A similar issue that emerged recently is
> udisks and friends, which is also optional according to upstream and not
> needed for people that want KDElibs for only a few apps and not for the
> full DE. We'd like to have some user feedback on this before our final
> decision.
This user's feedback, FWIW...
I'd like some clarification on udisks dependencies. When I installed 4.6
(a couple days before it was unmasked to ~arch, I believe, so by
definition still "raw", not complaining about that...)... I couldn't find
any way to turn udisks off. Not that I'd want to, necessarily, but I was
looking for the option.
The bigger issue, however, was udisks pulling in lvm2, etc, as
dependencies. Is that /really/ necessary? I had tried lvm2 on top of md-
raid here some time back and decided it was too many layers to work with,
debug, and worry about disaster recovery for, and unlike md-raid, which
allows direct kernel auto-assembly of / and thus does NOT require an
initramfs/initrd if root is built on it, lvm requires userspace assembly
and thus an initramfs/initrd if root is on it, so lvm got kicked to the
curb.
Needless to say I was *NOT* particularly happy about having lvm2 show up
in my dependency-merge lists again, especially when I tend to be very
cautious with automounting and such things anyway, tending to keep them
disabled (and I didn't enable dm in the kernel either, probably why kde
4.6's device-notifier appears to be broken, now, not that I really care,
as I said, but just the case)
But it seems if not for kdelibs or the basics, I'd still need udisks for
k3b to work properly, and udisks at least /appears/ to require lvm2
(probably for the device-mapper userspace, which is bundled with it now).
IOW, I don't so much worry about udisks itself, or udev, but is udisks'
currently mandatory dependency on lvm2 /really/ necessary? Do even things
like k3b's optical drive/disk sensing depend on lvm/device-mapper now? Or
is there a way to make that work while omitting lvm2, even if it breaks
automounting, etc, which I consider a security risk (especially after that
security presentation that made linux/floss news recently) in any case,
and really wouldn't mind doing without. If even MS is removing auto-play
stuff now, for security reasons... isn't Linux going backward if we're
replaying all the security mistakes MS is now leaving behind?
As for consolekit and policykit, pretty much the same thing, but here, I'm
primarily worried about security as the dependency tail didn't seem as
bad. Personally I have an "admin" user that I can sudo to (with password)
in a konsole, that in turn allows me from there passwordless sudo to
anything. That works well. I know where the config for sudo is and how
to change policies if I need to. Etc. I don't want or need the worry and
additional security exposure of an entirely different mechanism, used to
adjust system level settings also.
I don't /want/ system level changes made or even possible via what remains
to me kcontrol. So while others can enable those flags and use those bits
if they want, I definitely want the ability to turn that off via USE flags
retained.
Since policykit is the way those are handled, that'd be the USE flag that
needs retained. Consolekit similarly. It's additional complexity and
area of security exposure that I don't particularly want or need on my
system.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
signature.asc (0.19 KB)