[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Interfacing package management (was: KDE4: Running distro commands
From: "Friedrich W. H. Kossebau" <Friedrich.W.H () kossebau ! de>
Date: 2006-02-28 16:17:08
Message-ID: 200602281717.16236.Friedrich.W.H () kossebau ! de
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
Am Dienstag, 28. Februar 2006 15:46, schrieb Thiago Macieira:
> John Tapsell wrote:
> >Problem:
> > Quite a few program need to do distro specific things. Example:
> >skim is a kde applet for inputting asian characters. However the
> >asian language packs are rather large, so distros don't tend to
> >actually install the language packs. So skim needs a way to install
> >the language pack
>
> [snip]
>
> There's nothing the KDE project can do about that.
? There is. KDE should take the initiative to develop integrated support for
optional dependencies.
E.g. by creating a service type for package management with the needed
interface and have the distros implement a service which adapts to their
package management system.
So an optional dependency could be listed by the program e.g. by saying "Do
more with xyz installed. Install it?" instead of a dumb "Sorry, this feature
not available, xyz not installed."
The service would look up for the package which has the programm/plugin/data
with the given identifier inside or which matches the need (cmp. service
types), then would install the whole package(s), resolving all additional
dependencies as usual. The service could also tell if the wanted stuff is
available at all or offer to uninstall it (=turn manual dependency to
optional dependency again).
KTip would be glad to tip to helpful additional ksoftware and offer its
installation ;) Or KHTML for plugins, like Flash etc. Or Krita to
(un-)install all the plugins. Or KPilot to (un-)install the hexedit widget.
And there are surely more optional dependencies. Think of
KNotNewOnlyNotInstalledStuff ;)
> You have to talk to the distributions, freedesktop.org and/or the Portland
> Initiative.
This would be needed for an accepted standardization of the identifier names,
yes.
But isn't there already one, created by the naming and versioning of the
original developers? What kind of identifier conflicts could there be using
those?
I see, those distros who do subpackages would have to patch the identifier. So
if the applet requests the "$asian_languages" they would have to replace it
with all the identifier of the single asian language packets the distro has.
Needs some support by the framework, but should be solveable, perhaps by
reading the identifiers from external files which would have to be provided
by the package management system (cmp. i18n("")).
Perhaps the original developers should support identifiers which go into their
original packages as well. E.g. "kde/kdeutils/superkaramba" could be an
official identifer.
Hm, I feel reminded that I once started to plan such a framework myself :P
Who else would be willing to work on this now for real?
Regards
Friedrich
[Attachment #5 (application/pgp-signature)]
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic