RFC: On-demand package installation API in kdelibs
Lubos Lunak
l.lunak at suse.cz
Tue Aug 3 17:21:06 BST 2010
On Sunday 01 of August 2010, Dario Freddi wrote:
> So, I was actually already after such a thing and I've talked about it with
> Lubos already back in the Tokamak days. I didn't really have time to look
> at the implementation throughly,
If you're talking about my code, the implementation mostly doesn't matter,
the API does.
> however what I was doing (
> http://websvn.kde.org/trunk/playground/sysadmin/shaman/ ) was a slightly
> more complex and powerful thing. In the usual KDE fashion, that was a
> wrapper for various package management interfaces (packagekit, apt,
> $whatever) providing a high level interface to application to interact with
> package management.
>
> This indeed was meant to be integrated straight into the workspace: the
> whole API allows creating transactions, monitoring transaction and
> whatever, and is also able to perform some custom operations. A lower level
> API is also provided for creating package management GUIs. The final aim of
> all of this was to allow applications to ask the user to install stuff, and
> if the user agrees and authenticates (the whole deal obviously does not run
> as root), provide the progress straight into the system tray and make the
> whole experience less painful and more integrated.
Yes. And that is why there doesn't need to be any conflict, because my API is
not really meant to be "package management". It's just "I could use this",
that's all. It doesn't care what the workspace thinks about it, who will
actually do the job or anything like that. I've intentionally made it like
that.
The advantages I see are:
- it can work now. As far as I understood it you may still need some time
before moving out of playground, but meanwhile openSUSE or anybody else can
have their own backend for the time being.
- it can work anywhere. If e.g. Windows people decide to use it too, they
don't have to care about the rest of the package management stuff.
- you can see it as an optimized subset of your or any other package
management API for the most common tasks. Even if KDE ends up with an
official package management API, this still makes sense.
--
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