RFC: On-demand package installation API in kdelibs

Lubos Lunak l.lunak at suse.cz
Wed Aug 4 15:54:42 BST 2010

On Tuesday 03 of August 2010, dantti85-dev at yahoo.com.br wrote:
> >   KUpdateApplet does use a D-Bus interface from PackageKit. And that is
> > what breaks repeatedly. How hard can it be to keep backwards
> > compatibility for a D-Bus interface?
> If you don't know how hard it is you should start looking around
> package manager features.
> To give you an example, packagekit has it's primary goal on Fedora,
> simply because the author uses it. The API was made and fit the
> yum case, then I coded aptcc and the API wasn't good enough
> for APT, simply because apt can remove packages while installing
> and yum can't, so I took me looots o time to get into a consensus
> with the author about how to do a proper break that could be more
> future prof.
> Also you need to keep in mind the age of the software, PK is in version
> 0.6.6, and every new backend has some feature that we have to try to fit it
> in so it's not an easy task.
> PK 1.0 will sure have a much more stable API but to make it better
> we have to change it.
> KUpdateApplet would be much better if it uses packagekit-qt,
> which would give it at least compile checking. And yes we change
> we all change.

 No, we don't, kdelibs APIs stay stable until next major release. If you are 
aknowledging that using PK without a wrapper would not provide this, then 
it's not up to KDE's standards and we need our own API that can provide it.

> > > D-Bus is not that, but the services that are provide  through it are.
> > > http://packagekit.org/pk-faq.html#session-methods
> > > In the above link  you will how easy for an application to know
> > > if X component is installed  and even ask for install.
> >
> >  You've spent too much time with C code if you  think that is easy :).
> > Even if
> >
> > my proposal ends up being just a simple  wrapper around this, it is still
> > an improvement for developers.
> What 10-20 lines of code is hard?

 Every that is compared to 1 line of code.

> >  And  since Dario has another packaging system, it actually might be
> > beneficial
> >
> > to  have a simple API that'd hide whatever does the real work.
> That is a FDO standard which Dario can also implement on his
> package manager.

 Despite what some people would like to think, having something put "FDO 
standard" stamp on itself does not really mean much.

 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