RFC: On-demand package installation API in kdelibs

[Martin Sandsmark]

On Thu, Jul 29, 2010 at 04:29:22PM +0200, Hans Meine wrote:
> 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!

No, I assume a perfect implementation (I haven't brought up potential
security issues that may arise from an imperfect implementation).


> Exactly.  No point in discussing this.

So we agree that this API is a bad thing?


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

So you want automated, silent installation of unauthenticated third-party
packages from arbitrary repositories?


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

You just said everyone agreed that this was bad?


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

And leave the user non the wiser? Why not simply tell the user that the
needed libraries aren't available/crippled in all cases?

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

You just did yourself.


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

The we are _again_ back to the adding of clickthroughs and password entering,
which you just said everyone agreed was a bad thing, and we should avoid.


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

I still believe this is a fundamentally wrong approach, and that KDE
shouldn't endorse this.


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

Which can already be provided much simpler, with a plain old dialog.

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

I can think of several security issues that may arise, but the biggest is the
fundamental "avoid more clickthroughs".

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

Well, so far c) seems to have been the only reason to implement this API.


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

We already have a common message box implementation. :-)

-- 
Martin Sandsmark 
:wq