RFC: On-demand package installation API in kdelibs

[Lubos Lunak]

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