RFC: On-demand package installation API in kdelibs

Kevin Krammer kevin.krammer at gmx.at
Tue Aug 3 18:48:53 BST 2010

On Tuesday, 2010-08-03, Lubos Lunak wrote:
> On Thursday 29 of July 2010, Kevin Krammer wrote:
> > On Thursday, 2010-07-29, Lubos Lunak wrote:
> > >  You can't really notify and continue if you first need to wait for
> > > 
> > > something necessary for the proceeding.
> > 
> > Well, true, if it is something you absolutely need before you can
> > continue. But in this case it should be a package dependency and not be
> > allowed to be absent.
> > 
> > I though this was about installing optional things that could be
> > installed and enabled once present.
>  This thread has a number of examples where this is not the case. Mp3
> support (although there's it's not technical reasons). Installing
> additional language in the KCM. Installing debuginfo. Nepomuk backend
> missing (should really kdelibs hard-depend on it, even in the case it's
> disabled by default?). Clicking on an unhandled mimetype in Dolphin. And
> so on.

I agree that given a certain task as the main mental focus would suggest a 
"block until finished" approach.
However, I am cautious that this will be the case all the time, I expect this 
to be very related with the estimated time to finish.

Take the example of installing additional language packs.
Sure it might be the only thing the user wants to do right now, so blocking 
systemsettings at the respective page is OK.

But language packs or icon themes are quite big, so maybe the user would 
prefer to have the downloading and installing done in the background and 
notified when the new things became available?

The application would be available for other tasks, e.g. in the case of 
systemsettings changing styles or personal settings.

Applications which only solve one single task or can be started multiple times 
might get away with being unavailable for an uncertain time.
For multipurpose applications, especially KUniqueApplication ones, that's 
borderline unacceptable IMHO.

>  And even in the case when something "should" be a package dependency it
> doesn't sometimes make sense. Do you really want to install 100MiB of
> dependencies because an app may use it if you trigger one hidden button
> somewhere that 99% users won't ever use?

I already said I understand the importance I am questioning whether an 
application's only choice is to either wait or shutdown.

Package management already has several levels of dependencies to accomodate at 
least some of these situations, e.g. not depend on a package but recommending 

I am all for making the availability of such additional features more visible 
to the user and even extend it with non packaged additions, but if the addon 
is so crucial that the application will have to wait for its installation 
before it can do anything useful that should be a hard package dependency.

Like in the example of the Nepomukbackend: Nepomuk can't do anything without a 
backend, it doesn't make sense to install Nepomuk and not install a backend.
If the service provided by Nepomuk is the optional feature, then it should be 
optinally install able, not its backend.

Or when we look at Akonadi: we could make the request to install Akonadi 
server and its dependencies an option of kdepimlibs so apps which just offer 
addressbook integration as a feature for power users could link against 
kdepimlibs without dragging in all dependencies, but an application like 
KAddressBook would always hard depend on it, because its a requirement for its 
core functionality.


Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100803/5c9f3abd/attachment.sig>

More information about the kde-core-devel mailing list