RFC: On-demand package installation API in kdelibs

Josef Spillner (KDE) spillner at kde.org
Wed Jul 28 18:56:16 BST 2010


On Wed, 28 Jul 2010 16:17:13 +0000 (UTC), Sune Vuorela <nospam at vuorela.dk>
wrote:
> I am really against this kind of features.  Random applications should
> not ask to install other applications.

KDE doesn't understand packages, and I guess the reason for this RFC is
that some packagers don't understand KDE. One discussion thread is whether
integrating installation hooks into KDE is a good idea. Another one is,
assuming the outcome of the first discussion is that the installation is a
good idea, how to implement it. I'm not going to join the first discussion,
but would like to contribute a perspective to the second one with two
specific improvements over what has been suggested in the linked patches.
It's not a solution but a sketch towards a refined discussion of possible
realisations of the idea.

Each application could specify "features" as resource file or write them
to some log or (more fancy and buzzwordy) broadcast them to some D-Bus. A
distro-specific external application could translate the requested features
into passive guidance through browser invocation to some informational
page, active system package installation, random downloads from the
internets, syslog reminders for the local admin, do-it-yourself instruction
videos or just direct world domination. In particular, distributors and
administrators can opt to simply let it do nothing in a central policy
decision point. It's a classic mechanism vs. policy paradigm which is
usually a good idea in software design.
A second advantage over the other approach is that it would not add much
to kdelibs due to the externalised architecture.

A disadvantage could be the chaos in organising the features, but there
are ways around it, by requiring applications to specify their features
declaratively upfront.

An open issue, but equally applying to what Lubos has suggested, would be
the coverage and conveyance of features, i.e. which user-centric
application extensions can be detected this way and how the user can be
aware of their existence. For example, when I come across a KDE desktop and
it lacks the Italian l10n package, which application is going to help me in
this case apart from the usual installer? Would the systemsettings specify
that it can provide all sorts of translations and locales as features? How
could I navigate to systemsettings but not find the distro's graphical
installer application?

Josef




More information about the kde-core-devel mailing list