[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: RFC: On-demand package installation API in kdelibs
From:       Martin Sandsmark <martin.sandsmark () kde ! org>
Date:       2010-07-29 13:26:47
Message-ID: 20100729132647.GA467 () samfundet ! no
[Download RAW message or body]

On Thu, Jul 29, 2010 at 02:43:32PM +0200, Lubos Lunak wrote:
>  Might be a bad idea. Everything might be a bad idea. So do we ban changing 
> the clock because that requires the root password? KCMs that require root 
> access? KMail asking for account details? Screensaver password? Web logins? 
> There are already pages that tell people to download setup.exe and what to do 
> with the dialogs that show up, and can do the same with e.g. rpm. You make it 
> sound like this specific feature would suddenly skyrocket the number of 
> password dialogs.

You mention several usecases that should be improved (like using polkit for
setting the lcock, so the user doesn't have to enter the password), but the
point is to _minimize_ the number of dialogs the user has to click through
and enter his/her password into, not keep adding them.

(We could also make a distinction between cases where the user manually lock
something and need to unlock it, and randomly popping up dialogs because the
distro suppies crippled packages.)


>  Which still appears to be more often than possibilities to see a dialog 
> asking for installing additional packages.

This is still the result of the user explicitly doing something, as opposed
to, for example, the mediaplayer just proceeding to the next track.

And again, this is no excuse for adding _more_ dialogs.


>  No. They are in additional 3rd party repositories which need to be added 
> first, or the packages need to be installed in a different way, so they sadly 
> can't be installed in a simple way :(. But you don't install those every day 
> either.

Seriously, you want KDE to automatically download and install unverifiable
packages from 3rd parties?

And if this is something you don't do every day either, why can't we have a
slightly more cumbersome but much more secure and sane solution, ilke what
Sune proposed, instead?


>  But anyway, many people agree, some people disagree, and there doesn't seem 
> to be a middle ground. Since the default will be disabled and enabling will 
> require special effort from the packager, I will work on a suitable 
> implementation for submitting. Those that don't like it can just leave it as 
> it is (or add an "Are you stupid?" dialog first where only declining will 
> prove the user worthy of the feature, for all I care).

If you just ignore the feedback, what was the point of the RFC?

-- 
Martin Sandsmark 
:wq
[prev in list] [next in list] [prev in thread] [next in thread]