[packagekit] Extending PackageIDs to provide more information

Richard Hughes hughsient at gmail.com
Thu Nov 25 09:42:54 PST 2010

On 25 November 2010 16:38, Matthias Klumpp <matthias at nlinux.org> wrote:
> 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?

I think the package_id has to stay as a 4-tuple, not 4 or 5. It's
hardcoded in lot and lots and lots of places.

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

What about "name;version;arch;repo" and
"name;version;arch;installed(repo)"? Then clients that used to do a
string compare on the last data element can trivially be changed to
look for just the prefix. If a package backend doesn't support keeping
track of where a package came from then we can just emit
"name;version;arch;installed" like before.

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

I agree, getting the origin is a good feature.


More information about the PackageKit mailing list