RFC: On-demand package installation API in kdelibs

[Hans Meine]

On Thursday 29 July 2010 17:28:17 you wrote:
> On Thu, Jul 29, 2010 at 04:29:22PM +0200, Hans Meine wrote:
> > Exactly.  No point in discussing this.
> 
> So we agree that this API is a bad thing?

No.  We agree that there should not be unnecessary or too many or randomly 
popping up password queries.  (And, setting the clock is less dangerous than 
installing software, thus the password dialog is less necessary.)

With "No point in discussing this" I meant "No point in discussing that the 
number of unnecessary dialogs should be minimized".  We seem to disagree about 
when they are not unnecessary.

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

Not at all, and I thought I made my point clear.  

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

No.  I think everyone agrees that randomly popping dialogs would be bad, as in 
the first sentence ("when proceeding to another track").

Then, I started with OTOH ("on the other hand"), which means that in this case 
(explicit user action), a dialog would be justified.  And that dialog would of 
course not yet install anything or ask for a password, but just offer 
information, and allow to plug in a way to start the installation.

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

Here, I guess I was unclear.  With "that" in "But that would still be a bug in 
the media player ...", I meant that it's up to the media player to use the 
proposed API in a sane (useful, responsible, intended) way.  But we're not 
talking about the media player here but about the necessary hooks for 
packagers to allow installing stuff in a more convenient way.

Another view would be to call the proposed API object-oriented from a user 
POV.  The user stumbles over missing functionality (/missing packages) and 
shall be enabled to more directly resolve this problem, instead of manually 
locating and starting the correct application (the package manager) and 
finding the "object" (/"document", i.e. the package providing the missing 
functionality).

> > Of course not.  Nobody here would propose something stupid like that!
> 
> You just did yourself.

No, I never proposed to "automatically download and install unverifiable
packages".

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

I agree that they should be avoided *where possible*.  We just disagree on the 
point where they actually *make sense*.

You seem to think that a user should be told "that the needed libraries aren't 
available/crippled" and left alone with that information, so that he/she goes 
through the necessary steps to locate and install packages using a package 
manager started via the menu.  Does this procedure make the difference in your 
opinion, because the password dialog is hidden enough that only aware user 
will fill it in?

I assumed that the "clickthrough" effect could be leveraged by
a) minimizing the number of such dialogs,
b) optimizing their time of appearance, i.e. showing them in clear relation to 
explicit user actions, and
c) optimizing their appearance (concise, clear description of the situation 
and options).

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

I also prefer a distribution with all "batteries loaded", but obviously, the 
need for this is there and has already led to several inconsistent, partial 
solutions.

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

Is there really such a big difference between an app showing a "plain old 
dialog" and calling a central API function that shows this dialog in a 
consistent manner?  The latter should not put a too large burden on the 
programmer (except for knowing yet another API, but that's the price of 
consistency).

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

I thought that "clickthroughs" would describe a series of dialogs where you 
just press "OK"/Enter.  Wouldn't a package manager main window already make a 
difference?

I see a clear benefit even for experts; for instance I prefer to install stuff 
via the endorsed package manager whenever possible, but I hate finding out 
which package manager and package management GUI is the preferred one on which 
release of every distribution out there (i.e. when I help out friends with 
their Ubuntu/OpenSuSE machines, while I am running Gentoo).  And that's only 
part of the problem, locating the correct package is the next - while package 
names seem to become more similar across distros, this is still not trivial in 
many cases.

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

What about b)?  And even a) could be the reason, i.e. styling the message 
boxes in a consistent way, or adding links to distribution websites or the 
like.

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

OK, I see your standpoint. :-)

Hoping I made myself more clear this time,
  Hans