RFC: On-demand package installation API in kdelibs

[Lubos Lunak]

On Thursday 29 of July 2010, Martin Sandsmark wrote:
> 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.

 So? If you're fine with polkit for the clock, you should be fine with polkit 
for installing trusted packages too.

> >  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.

 Which is not the usual case. The usual case is also a result of the user 
explicitly doing something.

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

 Of course not. The useful feature is the excuse.

> >  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?

 No. Did I say that? Let see. No, I didn't.

> 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?

- Because we already do have it, today. Just check the dialog or notification 
next time something complains you don't have something installed. And nothing 
stops you, you can have it cumbersome forever if you want.
- Because I doubt it's more secure and it's definitely not more sane.
- Because most people prefer computers doing the work for them, and not doing 
work for computers.

> >  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?

 I'm not ignoring the feedback, I wouldn't be bothered with writing this mail 
otherwise. Also, not ignoring the feedback means also not ignoring all those 
people who say your concerns don't matter much in practice and who outnumber 
you.

-- 
 Lubos Lunak
 openSUSE Boosters team, KDE developer
 l.lunak at suse.cz , l.lunak at kde.org