[packagekit] app-install 0.1.0 released!

[Anders F Björklund]

Richard Hughes wrote:

>> But other than it works fine, and app-install-extract-package does
>> handle .tbz through the use of libarchive, so that should be simple.
>
> Excellent. I've committed your patch, thanks.

There's a problem when using "package" instead of "package_id".
It's more of a theoretical problem, but maybe what it needs is
another database field (something like "data" or perhaps "misc")
in addition to the current "v1" fields of package_name/repo_id ?

This is because the name is not unique, only the full pkgname is.
So if name must be unique, then I need to switch to using origins
instead, like the portage backend is doing. This will break stuff.
Or just ignore the name conflict, it shouldn't be all that common.

With rpm/deb, you would normally have to rename the package too.
(if you want to have two major versions installed of something,
without apt/yum offering to "upgrade"/remove the older version)
The tgz/tbz all have the same package name, but different origins.

Since the FreeBSD backend is intended to primarly install from
binary packages (where available) instead of from source ports,
it uses the pkgname rather than the origin. I believe the Gentoo
backend(s) is still missing binary support ? ("emerge --usepkg")


Adding such a field would allow it to handle multiple versions...

It's more generic than just AppInstall though, would also affect
PackageKit itself in order to read and store the (non-repo) data.

One "solution" would be to just allow one version for each name.

Breaking changes do get their own package name too, like qt4/kde4
or python27/python31. And everyone "should" upgrade, right ? :-)

--anders


PS. A "pkgname" is something like:
     firefox-3.5.11,1
     firefox-3.6.8,1

     An "origin" is something like:
     www/firefox35
     www/firefox