diff options
author | Michal Schmidt <mschmidt@redhat.com> | 2012-04-20 09:38:43 +0200 |
---|---|---|
committer | Michal Schmidt <mschmidt@redhat.com> | 2012-04-20 17:12:29 +0200 |
commit | 656bbffc6c45bdd8d5c28a96ca948ba16c546547 (patch) | |
tree | 72ae472a5d5bb05b7b5c8cfcceefbfce0898537b /LICENSE.GPL2 | |
parent | 05d576f1f77699ea5c2e5ed0e04451b14dfc45a0 (diff) |
transaction: rework merging with installed jobs
Previously transactions could reference installed jobs. It made some issues
difficult to fix.
This sets new rules for jobs:
A job cannot be both a member of a transaction and installed. When jobs are
created, they are linked to a transaction. The whole transaction is constructed
(with merging of jobs within, etc.). When it's complete, all the jobs are
unlinked from it one by one and let to install themselves. It is during the
installation when merging with previously installed jobs (from older
transactions) is contemplated.
Merging with installed jobs has different rules than merging within a
transaction:
- An installed conflicting job gets cancelled. It cannot be simply deleted,
because someone might be waiting for its completion on DBus.
- An installed, but still waiting, job can be safely merged into.
- An installed and running job can be tricky. For some job types it is safe to
just merge. For the other types we merge anyway, but put the job back into
JOB_WAITING to allow it to run again. This may be suboptimal, but it is not
currently possible to have more than one installed job for a unit.
Note this also fixes a bug where the anchor job could be deleted during merging
within the transaction.
Diffstat (limited to 'LICENSE.GPL2')
0 files changed, 0 insertions, 0 deletions