a44bed4af2
Most users of this just used ANY as the enum kind, and the backends were forced to do many more string matches than actually required. It was a dumb idea to try and codify all the different kinds of provides, as each time we had to wait for PK to release and backends to be updated before we could make use of any of the new types. No soname bump as we have not had a tarball release since we last bumped.
98 lines
4.3 KiB
Plaintext
98 lines
4.3 KiB
Plaintext
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 it's 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)
|