[packagekit] Making the spec more useful: DownloadFiles

Richard Hughes hughsient at gmail.com
Mon Sep 7 05:42:32 PDT 2009


As the spec mandates[1], backends are required to send Files() signals
when the DownloadPackages method is called. This is so the clients
know which files to copy (as the filenames often can't be guessed from
the package_ids) and also allows the bindings to copy the files on the
users behalf. It's also quite useful to know which package_id
corresponds to which file, as the downloads may be pipelined, and thus
finish in a different order to what they were requested in the array
of as package_ids.

The spec is pretty loose here, in that it doesn't specify what
package_id you have to specify for the download. The daemon cares even
less, allowing backends to pass gibberish over the bus as the
package_id parameter.

So what do the backends currently do?
* yum: appends all the files together, and sends it with the id set as
the first package_id in the list
* dummy: just sends one Files(), with NULL as the package_id
* smart: sends one Files() per package, with the package_id set correctly
* alpm: sends multiple Files(), all with the package_id set to NULL
* apt: doesn't appear to send Files() at all
* aptcc: sends one Files() with multiple files, and a NULL package_id
* poldek: sends multiple Files(), all with the package_id set to NULL
* ports: sends one Files() per package, with the package_id set correctly

So, varying degrees of fail.

So, I've improved the spec, and now mandate that each package_id sent
to DownloadFiles MUST generate an indervidual Files() signal with a
single entry for files set as the downloaded package file. This means
I can check the number of Files() in the daemon and warn if it's not
matching the number of ID's, and I can also validate the package_id
before passing it onto the bus. Client programs and bindings also know
what file corresponds to which package_id, which means things can be
pipelined without causing chaos.

Please ensure backends (alpm, apt, aptcc, poldek) are fixed in the
next 3 weeks before the next release -- I've already fixed dummy and
yum if you want to check how it should be done.

Thanks,

Richard.

[1] http://www.packagekit.org/gtk-doc/introduction-ideas-transactions.html#introduction-ideas-transactions-download


More information about the PackageKit mailing list