[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