RFC: On-demand package installation API in kdelibs

Lubos Lunak l.lunak at suse.cz
Thu Jul 29 14:00:29 BST 2010

On Wednesday 28 of July 2010, Sune Vuorela wrote:
> On 2010-07-28, Lubos Lunak <l.lunak at suse.cz> wrote:
> >  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.
> trying to comment on a api you actually don't think should exist, but
> well. trying anyway.
> It should provide info about
>  - who wants a feature

 KComponentData takes care of that

>  - why is the feature wanted
>  - what feature is wanted.

 QString reason. Ok.

 And are you aware that first you are afraid that users will just click the 
dialogs away and now you suggest they are overloaded with more details?

> if it should be a function:
> enum featurekind {
>     Executable,
>     MimeType,
>     Plugin,
>     DebugInfo
>     //To be extended
> };
> void tryProvide(const QString& appname, const QString& explanation,
>                 featurekind, const QString& feature);

 I originally tried that and it in fact led to worse API than the current way, 
as the variants differ slightly. E.g. the language functions John Layt 
suggested would work better with appname and language separate, debuginfo 
function needs a list of binaries, etc.

> I don't think the return type of the function actually is important,
> because the app should handle it gracefully anyways if it doesn't exist.
> (handling it gracefully can in worst case be calling exit();, but then
> the distribution people is having a issue, and maybe shouldn't ship the
> app in question).
> Or maybe, the function should be bool: wether or not anything has
> changed on the system and if diagnostics should be rerun.

 Return value true means that either the capability was already installed or 
that it has been installed as a result of the call. I've tried several ways 
and this one seems to be the simpler to use.

> And it should be noted, that this should not be a replacement for
> distriution packagers to actually do their job.

 ? Packagers will need to do their job in order for this to work.

 Lubos Lunak
 openSUSE Boosters team, KDE developer
 l.lunak at suse.cz , l.lunak at kde.org

More information about the kde-core-devel mailing list