IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This drops one line + whitespace line from each txn, and updates us to use
autoptr. Just a bit less duplication.
I noticed while doing this that not every txn initializes a cancellable, but not
shaving that yak right now.
Closes: #560
Approved by: jlebon
On Fedora 25, systemd adds a sysuser config file for multiple users. It
also explicitly creates those same users in its %pre, except for one:
systemd-coredump. This means that the tree's /usr/lib/passwd doesn't
contain systemd-coredump. Of course, on first boot, it gets created and
added to /etc/passwd.
During package layering, we map /usr/lib/passwd to the container's
/etc/passwd. If the %pre calls useradd/groupadd without passing an
explicit uid/gid, it's possible that the allocated id is already in use
by an entry in the deployment's /etc/{passwd,group} (such as
systemd-coredump, but the same holds for any manually-added entry).
We resolve this by taking the switcheroo a step further: we map
/usr/lib/passwd to /usr/etc/passwd, and then also map /etc/passwd to
/usr/lib/passwd. That way, useradd in %pre will account for already
allocated local uids and react accordingly.
Closes: #561
Approved by: cgwalters
During a deploy operation, we would fetch commit objects from the remote
to resolve the version string. If gpg-verify was turned on, we would
fail to pull them if some of the commits were not signed. This is
because we pulled them in batches. We partially address this by only
fetching the HEAD commit on the first pass. This allows `upgrade`
operations to work just as well as `deploy` operations.
Though there is still an issue if we have to traverse farther back than
when signed commits become unsigned (unless they happen to fall on a
batch boundary). We leave that unsolved for now, since that would likely
require a more complex solution and it's not clear whether it's a real
world issue (signers can just retroactively sign commits).
Copy the gpghome from ostree so that we can test GPG-related cases in
our suite.
Closes: #527Closes: #557
Approved by: cgwalters
Expand the available options in the Rebase() D-Bus method to also have a
"revision" key. Its value has the same semantics as the "revision" key
in the Deploy() method (e.g. the "revision=" and "version=" prefixes are
also supported). Also expand the rebase CLI to allow for specifying the
revision as an additional argument.
This allows users to rebase to a specific version or checksum, rather
than only to the latest. Conceptually, this is the equivalent of doing a
rebase followed by a deploy. I.e. we specify an override-commit in the
origin and expect the same behaviours that apply after a deploy to also
apply here.
Closes: #212Closes: #555
Approved by: cgwalters
I kept thinking `^a&s` was sufficient for allocation-free reading
of `as`, but it's not, we need to free the outer buffer. Other
minor cases were using `s` instead of `&s`.
Closes: #533
Approved by: jlebon
In the future we may add more commands that take as input commit
IDs. However, we really want to distinguish between server and
client generated commits, as some of these operations won't
make sense for derived commits.
This changes the API to have callers say which type of commit
they're generating, which also fixes a FIXME, and helps get us
a bit closer to the "unified core".
Closes: #520
Approved by: jlebon
Previously, in preparation for validating e.g. versions during 'deploy'
operations, we would pull the latest commit metadata. However, we would
then do resolve on the branch name only rather than the full refspec.
But this can sometimes give the wrong checksum. For example, if we have
multiple remotes holding the same branch name, ostree_repo_resolve_rev
will just start looking in each remote for the specified ref, and we may
thus end up with the checksum from the wrong remote.
Related: RHBZ#1390259
Closes: #507
Approved by: cgwalters
See https://github.com/projectatomic/rpm-ostree/issues/405
This patch adds an (off by default) `--enable-new-name` build option
which currently defaults to `nts`. This is purely additive, and
the intention is that we'll support the rpm-ostree name in
perpetuity most likely.
At the moment, we add a new name for:
- /usr/bin/$name
- The systemd unit file
But we notably *don't* attempt to add a new name to the DBus API,
as it'd be a lot more invasive of a patch, and less payoff (it's
mostly just programs/scripts that interact with the DBus).
Closes: #497
Approved by: jlebon
A funky behaviour of `rpm-ostree deploy` was that specifying a csum
directly allowed you to jump to any commit, regardless of whether that
commit exists on the current branch or not. We tighten that up here so
that we check that the checksum does exist on the current branch.
The previous behaviour can be useful of course, but we might want to
change how users access it so that we don't get inconsistencies such as
rpm-ostree status saying that we're sitting on a specific branch with a
specific commit which doesn't actually belong to that branch.
Closes: #495
Approved by: cgwalters
I'm trying to rebase my workstation across a major version, but
hit the issue that we were pointing libdnf at the current root,
and hence it inherited the major of 24, when my target base ref
was 25. In trivial cases this may work, but I have various things
like Emacs layered that caused dependency resolution failure.
The obvious fix here is to point libdnf at the target base ref.
However, until now we'd been checking out a minimal copy of the tree
*before* doing package upgrade resolution. I considered trying
to add `/usr/lib/os-release` to that set, but it doesn't seem
sustainable.
Particularly since I think the original rationale for this was that
the checkout was slow, but that was when we had `fsync()` on, which we
don't now.
Closes: https://github.com/projectatomic/rpm-ostree/issues/486Closes: #496
Approved by: jlebon
Commit 334cec56a0 had a fatal
logic error - I changed it to write a temporary ref for the final
commit, not the base.
I noticed this by getting `missing metadata object $base.commit` on my
desktop system. Hooray for dogfooding git master.
Closes: #452
Approved by: jlebon
It needs to be under `[Unit]`. I noticed the systemd warning
in my logs; not sure how this worked when I was testing it locally.
Closes: #446
Approved by: jlebon
Right now the daemon assumes the system is using ostree, but
for various reasons people can try to start it on non-ostree systems.
This is a simple fix to avoid crashing. A better fix would
need to rework a lot of the code to return dummy/stub values but
that would be painful. Maybe later.
https://bugzilla.redhat.com/show_bug.cgi?id=1372194Closes: #445
Approved by: jlebon
We need to manage our baselayer refs independently of the deployment
being written by libostree, so suppress the default clean; we'll do
it in rpm-ostree.
I noticed the `Freed objects:` message twice and always wondered why
until today.
Closes: #437
Approved by: jlebon
Until now, we weren't pruning the pkgcache repo at all. I ran out of
space in the root partition in my CAHC vagrant test box, so it's time
to fix this.
The basic algorithm is to walk over the full rpmdb contents of each
root, generate a set of "currently referenced" cached refs, then delete
any refs in the pkgcache repo which aren't included. Then, do a prune
of the pkgcache repo.
While we're here, factor out a `sysroot_upgrader_cleanup()` function
which does all of the cleanup. The idea is at some point we need to
introduce an `rpm-ostree cleanup` command or so which calls this, to
handle the case where the system is interrupted post-deploy but
pre-clean.
Closes: https://github.com/projectatomic/rpm-ostree/issues/428Closes: #437
Approved by: jlebon
In preparation for future changes here, rework things so
that we only walk the set of deployments once after the new
deployment has been generated.
To avoid a race where if we're interrupted after the deployment write
but before the regeneration, create a special `rpmostree/base/tmp` ref
that we delete after all the bases are regenerated.
Closes: #437
Approved by: jlebon
Currently, we do the final commit into the pkgcache repo, then
pull it to the base. The problem with this is that, combined
with the fact that we're not presently pruning the pkgcache repo,
we leak space.
In preparation for a cleaner fix for this, rework things so that the
core infra can know about *both* a base repo and a pkgcache repo. If
they're separate (as is the case for rpm-ostree-on-host), whenever we
are doing layering, explicitly pull just the `.file` objects that are
referenced into the parent repo. We do the final commit in the base
repo.
Closes: #437
Approved by: jlebon
Commit d153ece removes redundant transaction printing, but we do still
want to print it manually when we're doing a dry run.
Closes: #407
Approved by: cgwalters
This came up in #403, but looking at this more, I don't see a need to
print out the input package set here. The list of overlaid packages
is very clear in `rpm-ostree status`, and the user knows what they
typed on the command line.
Closes: https://github.com/projectatomic/rpm-ostree/issues/403Closes: #404
Approved by: jlebon
It's really in-your-face for admins to see `(unsigned)` which originally
was intentional, but in practice right now at least several major
users (Fedora, RHEL) don't enable GPG signatures.
So let's just hide it if not enabled.
Perhaps in the future we should add a `-v` option or something which
would show all of the fields even if not enabled.
Closes: #399Closes: #402
Approved by: jlebon
Since some of the DBus data like `CachedUpdate/commit` derives solely
from the ostree repo state, and `upgrade --check` only writes to the
repo, we need to watch for and reload from changes there too.
Closes: #392Closes: #400
Approved by: jlebon
Previously in #353 we changed this to not resolve the rev, but
that breaks the `CachedUpdateDetails` which actually wants it
to be resolved, to show pending updates.
This effectively reverts 749a5f03a8586392cafff949075c45a040d4e984
and changes things so we set `allow_noent=TRUE` and if there is
no ref, just return the deployment checksum.
Fixes: 749a5f03a8586392cafff949075c45a040d4e984
Closes: #392Closes: #398
Approved by: jlebon
In looking at this code, I noticed we were incorrectly mixing
`Option(GVariant)` with GError handling. If the deployment
had no refspec we'd return `NULL` but not set `error`.
Fix this by requiring a respec, and change the single caller that
relied on this to check outside.
Closes: #398
Approved by: jlebon
We don't have a lot of outstanding changes to the C code, so now seems
like a good time to do this. I implemented this with some highly
sophisticated sed commands like:
```
find -name '*.c' | while read name; do sed -i -e 's,gs_unref_object \([A-Za-z]*\) \*,g_autoptr(\1),' ${name}; done
```
Part of dropping the dependency on libgsystem, same as what we're
doing in ostree.
Closes: #393
Approved by: jlebon
The `rpmostreed_refspec_parse_partial` method would only work with
refspecs that include a remote. This was causing rebases to fail when
specifying a local ref. However, it should be perfectly valid to do
this. Adapt the function.
Closes: #371
Approved by: cgwalters
We would unconditionally call ostree's pull() regardless of whether the
branch we were tracking was remote or not. We need this to work to make
it easier to write tests, though it's a worthy addition on its own.
Closes: #371
Approved by: cgwalters
The origin might have an empty "requested" key in the "packages"
section, which is probably an indication that packages were once added
but were then removed.
Explicitly check the length of the pkg array in case it's actually
empty before adding the base-checksum to the deployment variant.
Closes: #371
Approved by: cgwalters
During the initialization of the daemon, it would try to load the
deployments and cache a few things. One of these steps wanted to look up
the rev of the deployment. However, if the rev no longer exists (e.g. we
just did a rebase, purged the ref, and rebooted), this would error out.
Replace the lookup by simply directly using the csum from the
deployment.
Closes: #353
Approved by: cgwalters
Rebasing on a new branch should not in any way care about which commit
we're currently overridden on.
Also fix a typo which would cause override-commit keys to not be
deleted from the origin.
Closes: #353
Approved by: cgwalters
Now that the `status` command learned a `--json` option, we can pretty
much avoid parsing human-readable output. The only piece of information
that is missing from the JSON output compared to the output for humans
is *which* deployment we're currently booted in.
This patch fixes that shortcoming by adding a "booted" boolean variant
to the deployment variant.
Closes: #350
Approved by: cgwalters
In order to make many things work, we need to run scripts. Short version:
For now, we:
- Run `%posttrans`
- Treat most `%post` as the same as `%posttrans`
- Ignore `%preun` and such since we never uninstall
Most importantly though, we start to build up an "override" list
for script handling. Currently it's just a blacklist of scripts
we don't need.
Significant work here would be needed to run Lua scripts, so far I've
been able to just skip them.
Closes: #338
Approved by: jlebon
We don't currently expect people to sign commits locally.
However, long term, I would like to support a verified boot model
where we still support layered packages. A system administrator could
log in and perform changes, and possibly use a remote hardware token
to sign the commit. Anyways that's for the future.
Closes: #346
Approved by: jlebon
We need the ability to both add and remove packages as one
transaction in the general case (`Conflicts:`), plus it'd
be quite nice to allow users to do multiple package things
before rebooting.
And finally, this deletes a lot of duplicate code.
Where I'm really thinking this should go is we only have one
transaction type internally for at least upgrade/pkg as a group.
Closes: #326
Approved by: jlebon
Right now, while one can `pkg-add strace`, there are a lot of
packages with `%post`. Since some current developers want
to use package layering as it is today, let's add the concept.
Even after we have a whitelist of scripts and have cleaned up Fedora
to use them, we'll still have potential issues with 3rd party RPMs
etc. for a long time, so allow people this out to stumble forward for
those and potentially run them by hand if necessary.
Closes: #311
Approved by: jlebon
A friend once convinced me that having two boolean arguments to a
function was bad, three or more really should be converted into flags
to avoid confusion.
I plan to add another.
Closes: #311
Approved by: jlebon
I think most users are really going to be interested in the base/origin
commit, and not whatever the stuff they made locally happened to hash
to.
Closes: #295
Approved by: jlebon
I really don't like doing a `g_warning()` in the middle of a call
stack and stumbling onwards. If we fail to load a commit, we should
pass the error back up to toplevel boundary - normally a DBus method
invocation. As opposed to giving partial or incorrect data.
This is a preparatory (git) commit for adding more data from the
(ostree) commit to the deployment variant.
Closes: #295
Approved by: jlebon
- `ostree_sysroot_get_deployments()` cannot fail (only assert)
- Relying on setting a GError to detect the rollback only to
clear it was a bit weird; instead just pass `NULL` there.
Closes: #295
Approved by: jlebon
Some code changes in the package layering broke this to always
error out with `refs are equal`.
Reading the code I was confused for a bit until it dawned on
me that `self->refspec` was the input, and we extracted the current
one in a different way. I ended up modeling it back on the last
working commit I saw (`9eabc1ba`).
That said the logic here could be cleaned up more...it feels like we
should just have a "dry run" flag for the rebase transaction core or
something. Anyways, going for a surgical fix now.
Closes: #299
Approved by: jlebon
This patch fixes up errors in the parent commit which added pkg-add.
Some of them are due to the rebase on top of the unprivileged
infrastructure.
- fix compile errors (due to libhif changes after rebase)
- delete duplicate prototype for rpmostree_sysroot_upgrader_deploy
- include allow-older in flags type
- fix change_upgrader_refspec to use g_strdup() (this was causing the
wrong old refspec to be registered)
- in builtin-status.c, check for NULL before joining the packages array
- sysroot-upgrader: fix gtype function names
- roc_context_prepare_for_root(): delete unused param
- assemble_commit(): delete unused param
- RpmOstreeSysrootUpgraderFlags: fix docs
- Fix sysroot property name and add reboot opt
Closes: #289
Approved by: cgwalters
This builds upon the earlier prototype in
https://github.com/cgwalters/atomic-pkglayer
The `.origin` file says for a replicated installation:
[origin]
refspec=local:rhel-atomic-host/7/x86_64/standard
If you then run `rpm-ostree pkg-add strace`, it will result in a new tree with:
[origin]
baserefspec=local:rhel-atomic-host/7/x86_64/standard
[packages]
requested=strace;
Work still remaining here is to teach `rpm-ostree status` and
`rpm-ostree upgrade` about this.
Closes: #289
Approved by: cgwalters
It's expected to be able to switch to something different when
rebasing, even if the current origin has unconfigured-state.
Closes#232
Pull request: #238
Approved by: jlebon
While I was debugging the tests, I wanted to run the daemon
interactively under gdb but still on the session. In our previous
logic this was only possible if we were exec'd by dbus-daemon which
made attaching gdb annoying.
Let's honor the environment variable consistently on client and
server.
Now that the internal reading methods operate on the mainloop, and we
know there can only be one write transaction at a time, it should be
safe to drop the internal mutexes (and multithreading).
Updates to the `OstreeSysroot` instance and DBus API all happen off
the mainloop now. The write transactions now use a separate
`OstreeSysroot` instance, and do not perform any changes to process
state on their own. We always reload state from disk.
I think this is a lot simpler to reason about from a correctness point
of view, at a likely negligble loss in performance for read
transactions.
I'd like to move towards a model where internal worker threads don't
touch the "main context data", i.e. we only use message passing (via
main contexts). This means we wouldn't use a mutex.
I find this model to be significantly simpler to reason about.
Every transaction runs in a thread now, and there's no real drawback
to consistently creating a main context to go with it always. Most
of the transaction types now do a pull, which needs it.
Now that we have `ostree_sysroot_load_if_changed()`, we know more
precisely (and cheaply) when things change. Use inotify to detect
changes as before, but we don't need a timeout because all we do is
call `fstatat()` which is basically free; the inode is going to be in
memory.
This will hopefully help with
https://github.com/projectatomic/rpm-ostree/issues/220
but more investigation is needed.
We were loading the list of osnames by walking the FS, but it's a lot
simpler to just extract the set of known osnames from the deployment
array.
This is part of an effort to unify the "sync cached state with disk"
code in order to address race conditions.
We can't rely on the the GLib hash functions not changing (or being
stable across host systems). Basically here we have a "stringified"
deployment...it might be simpler to just declare this stable.
There are many reasons why the daemon may not be able to start up. An
initialization error doesn't/shouldn't reflect a programming mistake,
but instead a runtime issue in the environment.
Thus, if we fail to start the daemon, we shouldn't use g_error(), which
dumps core. We should instead print the GError and clean up as nicely as
we can.
Resolves https://github.com/projectatomic/rpm-ostree/issues/194.
Determines a revision argument to either be a SHA256 checksum or a version
metadata value.
The revision string may have a "revision=" prefix to denote a SHA256
checksum, or a "version=" prefix to denote a version metadata value. If
the revision string lacks either prefix, the function attempts to infer
the type of revision. The prefixes are case-insensitive.
rpmostreed_commit_generate_cached_details_variant() returns NULL if the
origin checksum of an OstreeDeployment matches the checksum of a refspec,
which may also be the OstreeDeployment's origin.
I don't understand the reasoning for that, especially since none of the
callers are prepared to deal with a NULL return. Nor is there a comment,
so remove the check.
This was making the daemon crash on
rpm-ostree deploy --preview <current-deployment-checksum>
which should just indicate no package differences.
Deploy method locks the deployment at a particular commit by adding an
"override-commit" line to the origin file.
Upgrade method must undo the override so we always upgrade to the latest
available commit.
Deploy(revision) pulls and deploys a particular revision on the
branch of the currently booted deployment. The revision can be
expressed as a SHA256 checksum or as a version metadata value.
Similar to rpmostreed_repo_lookup_version(), except without pulling from
a remote repository. It traverses whatever commits are available in the
local repository.
rpmostreed_repo_pull_ancestry() downloads an ancestry of commit objects
starting from a given refspec. An optional visitor function is called
for each commit object. The visitor function can stop the recursion,
such as when looking for a particular commit.
rpmostreed_repo_lookup_version() builds on this by supplying a visitor
function that examines commit metadata for a particular version value.
When the version value is found, the commit's checksum is returned to
the caller.
Allows clients to see version, timestamp
and other detailed information along with
the rpm diffs for cached updates and rebases.
This will be used by the Cockpit interface.
Adds a CachedUpdate property that allows clients
to see version, timestamp and other detailed
information for pending updates. Additionally
changes to this property signal clients that a
new rpm-diff can be fetched with GetCachedUpdateRpmDiff.
This will be used by the Cockpit interface.
Various OS "diff" methods can run concurrently with whatever else is
going on since they don't have to obtain the system root lock.
Just to make sure there's no conflicts when writing deployments or
downloading RPM package details, use an internal reader/writer lock
to protect the critical sections of upgrade, rebase, rollback, etc.
Create and load a new OstreeSysroot and OstreeRepo instance as needed.
This ensures its internal state is up-to-date, since several ostree
commands can alter stored state without the daemon's knowledge.
I would prefer keeping persistent instances if these issues can be
addressed, as it would eliminate some inconvenient error handling.
But this way is safer for now.
Having the OS.Upgrade() and OS.Rebase() logic flows conflated in the
daemon had me nervous. A day's worth of debugging a failing test case
proved that nervousness well-founded. Split them into distinct backend
operations.
So the client side can read it back.
This replaces the GObject "sysroot-path" property in the wrapper class,
which created some additional daemon refactoring.
This closes a race condition where the objects might not be exported
by the time clients call methods.
Also delete the code in the "on name lost" handler - it's not going to
happen in practice (we don't allow replacement), and causes issues as
it may be run first before we get the notification that the name is
owned. github.com/cockpit-project/storaged has some better code here
which we could copy later.
This then in turn allows us to delete the "hold"/"release"
infrastructure. Basically the daemon will live forever in the
process.
If a client makes a request that is identical (that is, same method name
and same parameters) to an ongoing transaction, return the bus address of
that transaction. The client can then "tune in" to the progress messages.
(Remember the Transaction.Start() method returns a boolean to distinguish
a newly-started transaction from an ongoing transaction.)
The driving use case for this is a dropped ssh connection during a long
running transaction -- like "upgrade" -- and being able to reattach to
the transaction's progress messages mid-stream.
Few things to note:
- Cancelling a transaction no longer immediately destroys it.
- Transaction is destroyed when finished (or cancelled) and has
no client connections.
- If a client attaches to a finished transaction and calls Start(),
the transaction will re-emit the Finished signal to that client.
- The transaction bus address is not yet shared across multiple
clients, so multiple connections doesn't actually work from the
outside yet. It's just supported internally.
Change the ActiveTransaction property from the bus address of the active
transaction to a string tuple: (method name, sender name)
The bus address was only a placeholder, and not very useful since each
transaction only accepts one connection (presumably the method caller).
The current policy is to only allow the root user access to the Sysroot
and OS interfaces, but this can be expressed in the static bus config.
The long-term intention is to integrate with PolicyKit. Leave comments
in the code stating so but remove the unnecessary authorization handler
for the time being, just so there's less code to review.
Since the daemon can detect when the client closes its peer-to-peer
connection, simplify the API by converting the Finish() method to a
Finished signal that is only emitted once.
Internally, add a "closed" signal to transactions (triggered by a
closed GDBusConnection), and have the transaction monitor use that
instead of "finished" to know when to dispose of the transaction.
Because peer-to-peer endpoints don't get assigned unique names, the
sender == owner check is rendered useless. But I'm not sure we even
need a check since the transaction *is* peer-to-peer now.
One way to secure the returned bus address from prying eyes would be
to employ GcrSecretExchange, but this would only complicate the hand-
shake further and (imo) necessitate a public client-side function to
implement the handshake correctly.
Transaction progress and message signals are really only intended for
one recipient: the client that invoked the method. Use a peer-to-peer
connection for transactions so we're not spamming the system bus.
This entails returning a bus address rather than an object path in
methods that use transactions. The client opens a connection to the
bus address, connects handlers to the Transaction interface (on path
"/"), and then invokes the Start() method.
To finish a transaction, the client need only close the connection,
either explicitly or by terminating. The server will detect this
and clean up resources for that transaction.
Implementing a template pattern for transactions.
The TransactionClass is now abstract, and transaction_new() is replaced
with various method-specific functions like transaction_new_upgrade().
These custom subclasses live in a new file transaction-types.[ch].
Further, transaction_monitor_new_transaction() is replaced with
transaction_monitor_add(). So the handlers for "OS" interface methods
need only create an appropriate transaction instance and hand it off to
the transaction monitor.
Move as much as possible out of transaction_new() for the benefit of
subclasses. The GDBusMethodInvocation property for setting up D-Bus
properties and name watching in the constructed() method.
Turns out we do still need a Start() method after all. Not for lack
of trying, but I can't get away from the client and server doing some
sort of handshake at the beginning to avoid either raciness on the
client side or artificial delays on the server side.
I don't particularly like the "start" signal I've added -- I'd much
prefer subclassing -- but I'm trying to keep the changes incremental.
Expose the instance and class structures, move instance members to a
private structure. This is also towards having the TransactionClass
follow a template pattern.
libostree logs messages to systemd's journal and also to stdout.
Redirect our own stdout back to ourselves so we can capture those
messages and pass them on to clients. Admittedly hokey but avoids
hacking libostree directly (for now).
The ProgressEnd signal indicates to clients there will be no more
DownloadProgress or SignatureProgress signals in the transaction,
and any further Message signals should be output as separate lines
instead of replacing the previous progress message.
In other words, it's just a way of driving GSConsole remotely.
A few changes:
- Modify the D-Bus API to include a Finish() method instead of a Start()
method, the idea being the client calls Finish() to obtain the final
status and optional message once the transaction indicates it's done.
Calling Finish() also removes the transaction object from the bus.
- Introduce Transaction class as a thin wrapper for RPMOSTreeTransaction.
Stores the status info for Finish(), detects when the caller's bus name
vanishes, and emits various status signals to TransactionMonitor.
- Introduce TransactionMonitor as a factory class for Transactions that
also handles book keeping chores like tracking the active Transaction.
The Sysroot and OS interfaces share a TransactionMonitor instance.
This isn't finished yet but it shows the direction I'm going and some
issues I'm encountering.
The CLI layer has 3 different versions of upgrade now:
1) If --check-diff is given, execute it locally regardless of sysroot.
I'm not convinced this variation needs to be executed in the daemon,
but if it does we need a separate D-Bus method since it produces
different results.
2) Else if --sysroot is not "/", execute it locally. I don't think
the daemon currently indicates what sysroot it's operating on, and
even if it did I'm not sure the CLI should be talking to anything
but the "/" daemon.
3) Else if --sysroot is "/", defer to the daemon.
Obviously there's a lot of unwanted code duplication going on here.
I'd like to factor out the common parts and put them in libpriv for
reuse, but I'm also trying to preserve the CLI behavior and all the
various g_print() calls are causing a problem.
I was toying with the idea of adding a "message" signal to
OstreeAsyncProgress for miscellanous status messages. Those signals
could then be handled by either printing the message to stdout or
transmitting it over D-Bus via the Transaction object.
Some of those g_print() messages could then be moved directly into
the common libpriv functions and handed off to OstreeAsyncProgress.
Returns the object path for the given OS name.
This can be done entirely client side, but it requires connecting to
the object manager interface, requesting all the objects and sifting
through them to find the one with a matching Name property.
For some use cases this method is just more convenient.
Creates, configures and exports an RPMOSTreeTransaction object from a
GDBusMethodInvocation. The interface is exported relative to the object
path on which the D-Bus method was called.
