FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Desktop

 
 
LinkBack Thread Tools
 
Old 02-25-2011, 07:17 AM
"Andreas K. Huettel"
 
Default use flags consolekit and policykit

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?

Cheers, Andreas

--

Andreas K. Huettel
Gentoo Linux developer
dilfridge@gentoo.org
http://www.akhuettel.de/
 
Old 02-25-2011, 07:38 AM
Theo Chatzimichos
 
Default use flags consolekit and policykit

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.
 
Old 02-25-2011, 09:26 AM
Dale
 
Default use flags consolekit and policykit

Theo Chatzimichos wrote:

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.




Well, this user likes option 3. It is on and ready to go but we could
disable it if we didn't need/want it. Maybe this is a good addition to
the recently formed kde profile?


There's one vote.

Dale

:-) :-)
 
Old 02-25-2011, 10:06 AM
Duncan
 
Default use flags consolekit and policykit

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
 

Thread Tools




All times are GMT. The time now is 02:23 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org