[packagekit] Raising the quality of backends

Anders F Björklund afb at users.sourceforge.net
Wed Sep 10 14:36:09 PDT 2014


Richard Hughes wrote:

> Hi all,

Hi Richard!

> I'm starting to be a lot more strict removing backends that either
> don't compile, or are just unmaintained. Here's a list of what we've
> got, and some of the problems:

Seems you missed out the "slapt", but it was also unmaintained (2011).

Basically it was just a test to see if it was hard to write a compiled
module, having written a couple of scripted ones. It wasn't (very)...

It got replaced by the "katja" backend (in 2013), for Slackware Linux

> ports: unmaintained since May 2013, ignored cache-age, missing
> downloaded filter, missing application filter

The ports backend was replaced with one for pkgng, which probably
suited better for PackageKit (i.e. it's not called PortsKit is it,
and it doesn't really support running with "mock" for yum distros
if something happens to not be available as binary rpm packages)

For some reason they decided to keep it downstream, though ?

https://wiki.freebsd.org/SummerOfCode2013/pkgPackagekit
https://svnweb.freebsd.org/socsvn/soc2013/mattbw/backend/

Not sure if it ever flew, the (0.6) PK port only has ports/dummy.

I think that "portupgrade" is still being maintained, even with
pkgng in place, and the Ruby backend for PK should be salveagable.
It still would be nicer with a compiled backend, but it could be
made to play along if someone wants to use PackageKit with FreeBSD.

https://github.com/freebsd/portupgrade

> All these "new" features have existed for a very long time. I don't
> see the point in keeping obsolete and unmaintained backends, and so
> any backend that's been two years unmaintained without any of the
> stuff introduced since 0.8.x is going to be removed in the next few
> months. I've already removed the woefully out-of-date ones like yum,
> box, opkg and smart.

Funny, just made a release for the smart project a week ago :-)
(BTW I think that "SMART" is for the hard drive functionality)

https://github.com/smartpm/smart

But the problem for Smart was that the backend just didn't start
quick enough for PackageKit, being written in Python and loading
the entire package database into memory at start up. And since it
was cross-distribution, it never had any of the distro files etc.

That is, it only had the rpm and the desktop files which means that
it was missing out on the yum comps and the appstream appinfo etc.
(and the smart package got thrown out of Fedora too, no maintainer)
So I don't think there's any point in resurrecting that backend now.


I think you need the backing of a distro, in order to have a backend ?

And I still don't, 5 years later, so might as well remove them. Bye bye.

--anders



More information about the PackageKit mailing list