RFC: On-demand package installation API in kdelibs

Lubos Lunak l.lunak at suse.cz
Thu Jul 29 18:15:01 BST 2010

On Thursday 29 of July 2010, Martin Sandsmark wrote:
> On Thu, Jul 29, 2010 at 04:12:53PM +0200, Lubos Lunak wrote:
> >  So? If you're fine with polkit for the clock, you should be fine with
> > polkit for installing trusted packages too.
> You don't see the difference between allowing the user to change the clock
> without asking for confirmation, and installing unauthenticated, arbitrary
> packages from arbitrary sources without confirmation?

 I do. Do you see the difference between installing unauthenticated, arbitrary 
packages from arbitrary sources without confirmation and installing 
authenticated specific packages from specific trusted sources with 

> >  Which is not the usual case. The usual case is also a result of the user
> > explicitly doing something.
> Could you please enlighten me to the usual case, if not the application
> trying to use this functionality?

 I was replying to your "This [=KWallet] is still the result of the user 
explicitly doing something, as opposed to, for example, the mediaplayer just 
proceeding to the next track." The usual case is that the API is used as a 
result of an explicit user action, while the mediaplayer just proceeding to 
the next track is not the usual case. And, uhm, KWallet actually 
occassionally turns up seemingly without a reason too.

> >  Of course not. The useful feature is the excuse.
> It is still just an excuse.

 Excuse me for reusing the original sentence in the reply. I of course meant 

> But if you think training users to click 
> through and entering their passwords, as well as moving legal liability
> over to KDE, is worth it for band-aiding over distributions crippling their
> multimedia packages, I can't argue with you, only disagree.

 Since your arguments are mostly only your opinion, it seems I can't argue 
with you either, only disagree.

> > > >  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.
> 1.: You proposed this API to automatically install extra multimedia
> packages when missing.

 I proposed this API to install optional component packages when missing, 
which among other things may be also multimedia.

 And I didn't say it has to be automatic; while I didn't stress the opposite, 
e.g. from my blog post it's rather obvious that the user at least needs to 

> 2.: These multimedia packages are not available in the official, verifiable
>     repositories.

 That may happen to be the case.

> So yes, you did.

 No, I did not. That is only your interpretation.

> Unless you mean the distributions somehow can verify the 
> packages, in which case I don't have a problem with this.

 There are basically 3 possibilities:
- The distro can ship the multimedia stuff directly. No big deal, the API 
probably won't be even called.
- The distro can't ship the multimedia stuff directly, but can provide it as 
an addon (let's say, hypothetically, if the user first confirms a dialog that 
they don't live in the US), then the API can add additional trusted distro 
repository and install from there. No big problem.
- The distro can't ship the multimedia stuff in any way. Which means maybe the 
packages can be provided in some 3rd party repository by somebody else, but 
the distro can't use it out of the box. So there's no way the API can install 
these packages on its own, the user has to do manual intervention (e.g. 
adding the repo themselves during the process). No problem either, besides 
the user suffering.
> > - 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.
> I don't get that dialog, I have a package manager that handles this at
> installation time. :-)

 So Debian has only one installation option "Install everything and the 
kitchensync" :) ?

> > - Because I doubt it's more secure and it's definitely not more sane.
> I'm sorry, a perfect implementation will of course be secure, what I meant
> was that it would be bad from a security perspective (training users to
> click through etc.).

> OK, and sorry if I am very stubborn and rude.
> Noone has yet met my criticism, though (without being incoherent from
> sentence to sentence).

 Still some technical details that you have a problem with? I think there is 
no point in continuing the discussion about the disagreement on whether the 
benefits justify the possibility of stupid users getting trained to be even 
more stupid.

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

More information about the kde-core-devel mailing list