RFC: On-demand package installation API in kdelibs

[Martin Sandsmark]

On Thu, Jul 29, 2010 at 06:27:30PM +0200, Hans Meine wrote:
> 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.

OK, that's fair. I always think that they are unnecessary except when
launching applications (which involves a focus shift in the user).


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

So you want warning messages popping up about the untrusted third-party
repositories?


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

What about when it is an automatically generated playlist? (A bit far out,
but still...)

Also, interrupting the user like this, and not allowing him to proceed until
he clicks through the installation doesn't really sound good to me.


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

I understand why this seems very convenient, but as I've already explained, I
believe this leads to training users in bad behaviour, and also possible
legal risks for KDE.

Optional dependencies providing extra functionality is pretty clear when I
install applications here in the package manager I use, and I certainly don't
want applications starting to throw up dialogs in my face whenever I run
them because I might want extra functionality.


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

Isn't the point that the packages we want to install aren't available in the
official, verifiable repositories?


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

Well, they don't make sense when I'm listening to music or inserting a DVD,
but they do make sense if I want to install new software. :-)


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

No, because the user will have to make a conscious effort to understand, and
be aware of, what he's entering his password into/clicking through warning
dialogs for.

I also believe that this should make it clear that it isn't KDE's intent to
assist people with breaking the DMCA or whatever.


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

I agree, especially with point a and b (users are notoriously bad at
recognizing stuff, so I'm unsure how much a custom appearance will help).


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

I agree with this too (hard to argue with facts :-).


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

How much more consistent do you want the dialogs?
(Or rather; consistent in what aspect?)


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

Yes, when the user just wants to listen to his music, and is getting held up
by an "endless" series of windows (there are already people complaining about
this, on opensuse amarok launches an installation of mp3 codecs that require
approximately 20 clicks to get through).


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

Then the solution would be to help Dario et al with Shaman, so we can get a
consistent package manager interface on all distros. :-)

(And if finding the correct package names are a problem, I would say that it
is a problem with the distribution, and should be fixed in said.)


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

b) gives you most of the same downsides as c, with the added overhead of
launching the normal package manager. :-)


> Hoping I made myself more clear this time,

I hope I'm not too confrontational, I'll go and eat now, and get some blood
sugar...

-- 
Martin Sandsmark 
:wq