RFC: On-demand package installation API in kdelibs

[dantti85-dev at yahoo.com.br]

> > KPackageKit besides some bugs of crashes is widely  adopted,
> > Fedora, Ubuntu and many others use it by default.  PackageKit
> > API does change since it's a 'new' project and some  backends
> > demand changes (I myself are responsible for many breaks  because
> > of aptcc). I think KUpdateApplet have a busy maintainer because  the
> > fixes are fast, since most breaks are really simple. I also  never
> > received an email of him complaining about packagekit-qt.
> 
>   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.


> > 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? which using QtDBus is even easier...

>  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.