[packagekit] Extending PackageIDs to provide more information

Matthias Klumpp matthias at nlinux.org
Thu Nov 25 08:38:57 PST 2010


Hi!
Currently, PackageKit package-ids do have the following form:
name;version;arch;data
Data is very often used to hold the origin of a package, the repository
where it can be found.
For example:
 csup;20060318-5;x86_64;fedora-devel

As soon as a package is installed, the repository data is no longer
accessible, the data is now used for the state of the package:
 csup;20060318-5;x86_64;installed
or if an update is available
 csup;20060318-5;x86_64;security

To have a unique identification of a package, the information about its
state is not absolutely necessary. I would like to encode the origin of a
package permanently in the package-id. This would be nice to easily group
packages by their origin (backports-source, security-repo or one of dozens
of PPAs, if you're a Ubuntu user) and to make the Listaller implementation
easier, on which I am currently working.
So, would it be posible to change to package-id format to something like
"name;version;arch;repo;[data]" where data is optional and only set if the
package is actually installed or if an action like updating is required?
As an alternative, this state-info could be moved to the detail info about
a package. Package-ids should be an unique identification of a package on a
system. If I make a search for a package, its state is not relevant, it is
extra-information, while its repository is essential, IMO. (Imagin you want
to downgrade a package to a version which is in another repository, or undo
the last set of updates - you just ask to install the original package by
using the package-id with an extra "repo" flag.)

Changing the package-id to something I explained above might not be useful
for the PK-user profiles, but it gives some advanced abilities to more
professional users while not confusing the normal end-user. It is also
required for me to store the origin *and* the state of a package somewhere
at the same time.

Applying a change like this would probably break all frondends and
backends, which need to be adjusted. So, are there comments on this? Maybe
I'm wrong and there already is a smart way to store repo and state in a
package-id at the same time... Otherwise I would like to know if you
consider the proposed changes useful.
Kind regards
   Matthias Klumpp




More information about the PackageKit mailing list