RFC: On-demand package installation API in kdelibs

Trever Fischer tdfischer at fedoraproject.org
Tue Aug 3 15:47:15 BST 2010


>
>  Hello,
>
>  I'd like to add API somewhere to kdelibs that would make it easy for
> applications to install additional packages if they find out some
> functionality is missing. The 11.3 release of openSUSE already has this
> feature, you can read about it at [1].
>
>  In short, there are actually quite some places in KDE where this could be
> used, but currently the code just does some kind of error message and
> shrugs
> it off:
> - Nepomuk will give a notification about Virtuoso not being available and
> that's it
> - Amarok will complain about MP3 support not being present (which is the
> case
> by default with some distributions because of legal reasons) and will try
> running a specific script to install it
> - DrKonqi has another implementation of running an executable for
> installing
> debug packages, specified as CMake argument
> - clicking on some files in e.g. Dolphin can show the 'Open with...'
> dialog if
> no application has been found to handle the file, but then usually the
> dialog
> is useless if the application is not installed
> - and so on
>
>  In most of these cases the user has to manually do what can be done
> automatically with today's packaging systems, and in fact those can do it
> better, since they can much more easily find out which package can handle
> mimetype application/foo or provide binary bar.
>
>  So the idea is to provide simple API in the form of 'bool
> tryToEnsureInstalled{MimeType|Binary|Whatever}( QString name )'. Various
> KDE
> code will call it when it finds out something is missing and maybe the
> call
> solves the problem.
>
>  I'm currently not proposing any specific code, as I'm first interested in
> feedback. The openSUSE 11.3 kdelibs code is in [2] (that's including
> making
> KRun use it before resorting to KOpenWithDialog), an example of use can be
> e.g. the patch at [3] making Amarok use this API instead of its own code.
>
>  The idea is that upstream kdelibs only provides a header file (attached
> is
> the public API as used in openSUSE) and dummy code, packages would/could
> provide their implementation that'd actually do the work. KDE developers
> would just basically change from
> 'if( !somethingNeeded()) { complain(); return false; }'
> to
> 'if( !somethingNeeded() && !KSUSEInstall::install( "somethingNeeded" ))
> {complain(); return false; }'.
>
>  I'm not sure what to call it (KInstall?) and where to put it - this is
> needed
> by KRun in libkio and may be even later needed by something lower, but it
> should be able to use kdeui).
>
>
>  Comment, questions, suggestions?
>
>
> [1] http://www.kdedevelopers.org/node/4232
> [2]
> https://build.opensuse.org/package/view_file?file=ksuseinstall.diff&package=kdelibs4&project=KDE%3ADistro%3AStable
> [3]
> https://build.opensuse.org/package/view_file?file=ksuseinstall.diff&package=amarok&project=KDE%3ADistro%3AStable
>
> --
>  Lubos Lunak
>  openSUSE Boosters team, KDE developer
>  l.lunak at suse.cz , l.lunak at kde.org
>
So... PackageKit?


-- 
Trever Fischer (tdfischer)
Fedora Ambassador, KDE Hacker
http://wm161.net
GPG: C40F2998 hkp://wwwkeys.pgp.net





More information about the kde-core-devel mailing list