[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: RFC: On-demand package installation API in kdelibs
From:       "Trever Fischer" <tdfischer () fedoraproject ! org>
Date:       2010-08-03 14:47:15
Message-ID: 2977.66.218.139.82.1280846835.squirrel () webmail ! tuffmail ! net
[Download RAW message or body]


> 
> 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@suse.cz , l.lunak@kde.org
> 
So... PackageKit?


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


[prev in list] [next in list] [prev in thread] [next in thread]