RFC: On-demand package installation API in kdelibs

[Hans Meine]

Hey Martin,

I clearly see you being opposed to what I believe would be a bad thing, but 
why do you assume the implementation to suck?  All your arguments do not hold 
with a good implementation!

On Thursday 29 July 2010 15:26:47 Martin Sandsmark wrote:
> 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.

Exactly.  No point in discussing this.

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

Everybody so far agreed that randomly popping up password dialogs are evil, so 
please stop bringing this up.

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

Of course, a mediaplayer should not try to have something installed when 
proceeding to another track.  OTOH, if you explicitly drop a number of files 
on the playlist, it would make sense to tell the user that these files are 
only supported with additional packages.  Then, if the user presses the "Sure, 
I understand, then please install that piece of software now" button, a 
package manager might eventually ask for a password (if no trusted source etc. 
is available).

Otherwise, unsupported files should simply be skipped.  But that would still 
be a bug in the media player, not in the proposed API.

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

Of course not.  Nobody here would propose something stupid like that!

A distributor might decide to offer password-less installation from trusted 
sources, but could still offer a more verbose, "are-you-really-sure?"-path for 
installing from 3rd-party sources.  One does not preclude the other, does it?

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

We can.  The point is that it would be up to distributors/packages to decide, 
which will also depend on the target audience.

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

The feedback is not ignored AFAICT, but the point is to
- offer an API to prevent (or even reduce existing) code duplication, and
- offer an entry point for distributors to hook into their package managing 
solutions.

As I see it, the API makes three solutions possible:
a) Simple dialogs instructing the user to install something (which would 
obviously be the default for people compiling from unpatched sources, at least 
for now).
b) The same, but including a way to directly open package managers with the 
desired packages/options being preselected.  (Easier and faster to use, no 
security thread here, is there?)
c) A more automated procedure with simple confirmation dialogs.

You might be against c) (and I can see why), but please don't confuse that 
with the introduction of a common API to make unified solutions possible.

I see this as a worthwile goal, exactly the goal of KDE: To have reusable 
pieces of software needed in many GUI apps, which also make applications look 
and behave more alike, and thus improve the user experience.

Ciao,
  Hans