Guide to porting backends from 0.8.x to 0.9.x

 * Do not use pk_backend_job_message() -- either use an error if the transaction
   cannot or should not be run or just do the right thing. Users don't want to
   see technical messages from a package manager.

 * Remove the PkProvidesEnum parameter from pk_backend_what_provides() -- all
   provides should be done as if ANY is specified.

 * Remove pk_backend_get_provides() from any backend that implements it, it's no
   longer needed.

Guide to porting backends from 0.7.x to 0.8.x

 * Remove any Simulate* methods from pk-backend-*.c

 * There's no such thing as UpdateSystem anymore

 * Rename the 'gboolean only_trusted' arguments to
   'PkBitfield transaction_flags' in the following methods:
  - InstallFiles
  - InstallPackages
  - UpdateFiles

 * Add a 'PkBitfield transaction_flags' argument to the methods:
  - RemovePackages

 * If PK_TRANSACTION_FLAG_ENUM_ONLY_SIMULATE is set in transaction_flags
   then depsolve and return what would be done. Treat this just like
   the Simulate* methods, i.e. emit what would be done in an actual
   transaction.

 * If PK_TRANSACTION_FLAG_ENUM_ONLY_DOWNLOAD is set in transaction_flags
   then depsolve and download any packages or metadata, but don't
   actually make any database changes or change any files

 * Switch the RemovePackages() arguments to match the DBus API if you're
   using a spawned backend, i.e.
   transaction_flags, package_ids, allow_deps, auto_remove

 * Remove any references to Rollback, it's no longer available.

 * pk_backend_job_thread_create now takes an additional user_data and
   GDestroyNotify parameter. The thread functions themselves now return
   void, rather than gboolean.

 * All the pk_backend_foo() backend functions that are intended to be
   run in a transaction take an additional PkBackendJob parameter after
   the PkBackend. Hopefully I've done a lot of the heavy lifting, but
   you might have to change a few (backend) to (job)'s yourself.

 * The pk_backend_get_uint() functions are removed, and threaded
   backends should now parse the GVariant params which is specific to
   the job, not the backend.

 * Remove any calls to pk_backend_set_sub_percentage() and replace them
   with calls to pk_backend_job_set_item_progress(package)

 * Spawned backends (i.e. those using pk_backend_spawn_new) *must* now
   manually set the backend by using pk_backend_spawn_set_backend() in
   pk_backend_initialize().

 * pk_backend_job_update_detail now takes a gchar** rather than a gchar* for
   the updates and obsoletes fields. No change is required for spawned
   backends.

 * pk_backend_job_update_detail now takes a gchar** rather than a gchar* for
   the vendor_urls, bugzilla_urls and cve_urls fields.
   All backends should remove any URL title (the bit before the ';') and
   *just* send the array of raw URLs.

 * Add calls to pk_backend_set_locked() to declare when your backend holds
   write-lock on its database. PackageKit will spawn multiple transactions
   which can read the database at any time. Not using this method will cause
   your backend to fail, as we then try to create multiple write transactions
   too.
   See the dummy backend for some examples.

 * Make your backend is threadsafe, so tasks can be executed in parallel.
   If your package manager is not threadsafe, create a new process and
   do IPC from the main thread, or - if possible - change your package manager
   to be threadsafe.
   If you managed to do this, add a new backend function
   "pk_backend_supports_parallelization" and let it return TRUE, so PackageKit
   can enable parallelization for your backend.
   Otherwise, PackageKit will fall-back to the old, non-parallel behaviour.
   Please try to enable parallelization, and use the non-parallel approach only
   if you have to, as some frontends will likely start to rely on beeing able
   to request data in parallel.

 * Fail any transactions which requires lock with PK_ERROR_ENUM_LOCK_REQUIRED.
   PackageKit will then requeue the transaction as soon as another transaction
   releases lock. If the transaction fails multiple times, PK will emit the
   PK_ERROR_ENUM_CANNOT_GET_LOCK signal to frontends. If you continue to use
   this in your backends directly, your backend won't work properly with
   parallel transactions.
   (if you don't use parallelization, you can still emit CANNOT_GET_LOCK)