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 is the first step towards unifying how we introspect packages from
a specific commit. We currently do this in three ways: libdnf, librpm,
and now `rpmostree.rpmdb.pkglist`. I'd like to get to a point where we
only have `rpmostree.rpmdb.pkglist` and libdnf, the latter only when
more complex queries are required.
This patch teaches the `db diff` command to make use of the new db diff
API so that it can work even on metadata-only commits. This is relevant
for use cases mentioned in #558.
I didn't get rid of the `rpmhdrs_diff` functions right now because of
the `--changelogs` option: libdnf currently does not expose this, so we
fall back to the previous API in that case. OTOH, I wonder how much it's
actually used in the wild; maybe we could just nix it?
Closes: #1162
Approved by: cgwalters
Add a function that can smartly perform diff operations on sorted
RpmOstreePackage arrays and make the db API use that. This allows us to
immediately take advantage of the benefits in a few places where diffs
are performed, including post-deployment tree diffs, and the legacy db
diff variant API. The upcoming `CachedUpdate` rework will also make use
of this (but with the notable difference of setting `allow_noent` to
`TRUE`).
Note this introduces a new `rpm_ostree_db_diff_ext` public API which has
the same interface as `rpm_ostree_db_diff` but also takes flags.
Closes: #1162
Approved by: cgwalters
In order to make use the new pkglist metadata more consummable, let's
add a function to create RpmOstreePackage arrays from it. Since some
APIs need to keep working as before, we use a `allow_noent` parameter to
distinguish between the two cases.
This is prep trying our best to make use of this metadata when possible
rather than checking out the rpmdb and initializing a `DnfSack`.
Closes: #1162
Approved by: cgwalters
Rather than letting the terminal wrap our line and go unindented on the
next line, let's do the wrapping ourselves to tidy up the output.
Closes: #1159
Approved by: cgwalters
Prep for `compose tree --ex-jigdo`; basically we want to generate the jigdoRPM
and only then set the ref to help bind the two things together. The main
thing to achieve is that if generating the jigdoRPM fails, the ref isn't
updated.
Closes: #1161
Approved by: jlebon
This is used in critical paths like pungi, so let's be sure it works;
the semantics are a bit subtle as it overrides setting the ref.
Closes: #1161
Approved by: jlebon
Basically reduce these functions to no-frills `DnfSack` utility
functions with the same implied warranty as
`rpmostree_get_matching_packages` and `rpmostree_sack_get_by_pkgname`,
which also operate directly on the sack.
These functions will be used from more places in the upcoming
auto-update patches.
Closes: #1158
Approved by: cgwalters
To make the new pkglist metadata even more usable, let's insert it
sorted. This ensures that we can bsearch the GVariant on the
client-side.
Enhance the bsearch utility function we have to deal with duplicate key
names. Although this is not the case today in rpm-ostree-managed streams
I know, some packages are allowed to have multiple versions installed,
so let's make sure we handle that deterministically by always returning
the first (earliest) version of the package.
Closes: #1158
Approved by: cgwalters
This function returned both an RpmOstreeRefsack and a pkglist bound to
the refsack. Interestingly, there were only two users of it, and one of
them didn't even make use of the pkglist functionality. Since the
lifetime semantics of this function are tricky, let's drop it and
introduce a dedicated function just for returning package lists.
I also dropped the `GCancellable` argument, since it isn't/can't easily
be used by those code paths.
Closes: #1158
Approved by: cgwalters
The new `rpmdb.pkglist` metadata is a cheap way of retrieving the set of
packages in a commit. I'd like to make use of it as much as possible vs.
checking out the rpmdb and setting up a DnfSack.
Of course, in the case of layered commits, it doesn't matter *as* much,
because a layered commit being present in the repo should mean that a
deployment is currently using it, and we should learn to reuse the rpmdb
checkout of that deployment. Though keeping it consistent across both
server and client commits makes implementing `OstreeDeployment`-agnostic
things like `db diff` more efficient too. I also plan to use this in the
upcoming auto-update code.
Closes: #1158
Approved by: cgwalters
It makes it harder to keep track of ownership except in the trivial
`_new ()` case for which they were designed (i.e. shoving straight into
another glib GVariant function that takes ownership of it right away).
Closes: #1160
Approved by: cgwalters
In the case of a rebase to a fresh remote, we want to make sure our
`OstreeRepo` picks up the new remote before we try to parse its
deployment. Otherwise, we'll error out when trying to fetch configs for
it.
This was picked up after turning on strict errors in the GPG
verification process.
Closes: #1160
Approved by: cgwalters
Prep for more work.
We actually pass a `GError` to the gpg results function and fail for any
other failures than gpg signature verification. (In that case, we want
to make sure that information gets to the D-Bus API level, so killing
the daemon would be the wrong choice).
I also factored out all the logic in
`rpmostreed_commit_generate_cached_details_variant` into a separate
function. This is prep for reusing it elsewhere.
Closes: #1160
Approved by: cgwalters
This is minor, though the list of methods we support is getting long and
will get longer. Let's just add some order to it to make it easier for
humans to parse.
Closes: #1160
Approved by: cgwalters
Prep for more work.
This also involved changing the functions from pointer return values to
`gboolean`.
I also made functions that didn't really need to be public become
private and fixed some indentation.
Closes: #1160
Approved by: cgwalters
This allows our bwrap API to really be more of a wrapper around
`GSubprocessLauncher` rather than having to hold data like the
environment itself.
Closes: #1157
Approved by: jlebon
More prep for `-Werror=undef`. Ideally we'd actually have these be defined but
that seems painful with autotools; for a later date.
Closes: #1156
Approved by: jlebon
This matches reality; I picked what's in CentOS 7 mainline today. More
importantly this also fixes a build error with `-Werror=undef` because we had a
trailing underscore `_` at the end and never noticed.
Closes: #1156
Approved by: jlebon
Minor follow-up to previous commit. It seems a bit confusing to allow
specifying `download-only` and `dry-run`. The former already includes
all the steps in the latter but goes further, as documented. Let's check
for this combination.
Closes: #1155
Approved by: cgwalters
Minor regression that crept in during the `--download-only` work. We
would download and import packages even when `--dry-run` was given.
Make sure we stop right after printing the transaction.
Related: #1128Closes: #1155
Approved by: cgwalters
We were calling the wrong completer function for `SetInitramfsState()`.
Not that it mattered much in compiled form since both ways ended up
calling the same internal gdbus function with the same arguments.
Closes: #1155
Approved by: cgwalters
This is highly dependent of the outcome of [1], though until that's
settled there, let's at least update the description to something a
little more apt. It feels more appropriate to consider rpm-ostree as a
"system manager" than just a "package manager" (which it certainly is
too of course). Also use Title Case convention which seems more popular
overall and looks nicer.
[1] https://github.com/projectatomic/rpm-ostree/issues/405Closes: #1155
Approved by: cgwalters
Minor polish item; `output_message` already prints a newline at the end.
Looks nicer without the double empty lines when refreshing metadata, and
no lines when cached.
Closes: #1155
Approved by: cgwalters
I just rebased my pet container to F27, and this was the only hiccup
when trying to build rpm-ostree. Basically, gdbus-codegen is sensitive
to how it's called when trying to find its own Python modules. Calling
it with the explicit `/usr` prefix works around that. This was fixed
upstream in [1], but hasn't made its way down the metaphorical stream
yet. See [2] for more information.
[1] b9f2ea4235
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1485853Closes: #1153
Approved by: cgwalters
This would have prevented corruption I saw when using unified core 🌐 mode; we
ended up appending repeatedly to the version in the imported pkgcache repo
where fedora-atomic does:
`echo 'Storage=persistent' >> /etc/systemd/journald.conf`
See also https://pagure.io/fedora-atomic/pull-request/97Closes: #1151
Approved by: jlebon
This fixes another thing broken with `compose --ex-unified-core`;
for e.g. `/usr/bin/ping` from `iputils`, the classic example of a filecaps
binary.
As I'm writing this commit message I realize it will actually also
take effect for package layering unnecessarily; we'll pointlessly
break the hardlink. But eh, it doesn't matter right now, we can
optimize that later.
Closes: #1151
Approved by: jlebon
Prep for adding `compose tree --ex-jigdo` to do both at the same time.
Changes other than code motion were minimized; the main thing was tweaks around
the initial option processing to call the API.
Closes: #1146
Approved by: jlebon
Rather than entirely symlinking `systemctl` → `/bin/true`, in order
to e.g. have NetworkManager be enabled, we need to process presets.
This is one of the things that's breaking FAHC where I did a
`--ex-unified-core` deployment.
(Actually it's a bit tempting to run a mass preset pass at the end,
but for now let's do this)
Implementation note: this is our first use of GResources, which
is a handy way to embed data into our final binary.
Closes: https://github.com/projectatomic/rpm-ostree/issues/550Closes: #1148
Approved by: jlebon
This rolls up several libglnx changes: https://github.com/GNOME/libglnx/pull/101
Now of course things are trickier here because we have an internal
abstraction over directly emitting to a console versus sending the
result over DBus. Further complicating things is that some things
call into libdnf and thus *require* use of `DnfState` which does
not give us the "n items" information, versus other parts which
we implement and can do what we want.
Even *further* complicating things is that we have to take care around non-CLI
callers like Cockpit; so I didn't try to pass the "n items" over DBus, rather
just reimplemented the "insert into text" that libglnx is doing.
Anyways overall this looks better IMO for all cases.
Update submodule: libglnx
Closes: #1143
Approved by: jlebon
The jigdo ♲📦 effort really throws a spanner into the logic behind our whole
code layout; so far I mostly sidestepped that by having a lot of the new logic
in the CLI, with just some `_jigdo_xxx()` methods in core code.
But in order to start on having the "sysroot" side use jigdo, let's start
moving some bits into core.
Closes: #1144
Approved by: jlebon
This is prep for a rework of
https://github.com/projectatomic/rpm-ostree/pull/621
For a no-op `rpm-ostree upgrade` (i.e. no updates available), as long as
layering is enabled, we pay the cost of checking out the base tree, *mostly*
only to get the base rpmdb.
This is prep for fixing that down the line by knowing we always have the "base"
tree's rpmdb checked out. Then in the layering case we only modify
`/usr/share/rpm` (eventually that will point to `/usr/lib/sysimage/rpm`).
Teaching `rpmostree-core.c` about this can follow on later.
Closes: #1142
Approved by: jlebon
This came out of discussion in: https://github.com/projectatomic/rpm-ostree/issues/1132
Let's simplify some logic and download/import even unused packages;
i.e. packages which do not provide any content objects.
A lot of the higher level logic wants to reference what I'm going to start
calling the "installSet" i.e. the packages in the rpmdb in the commit. So it's
simpler if the "jigdoSet" is exactly the same thing as the "installSet", and the
cost is pretty small.
Closes: #1140
Approved by: jlebon
Now that we have the jigdoset in `Requires`, let's make a hard
switch to using it and drop the jigdoset from the jigdoRPM data.
One lingering concern here is that the `Requires` are not quite
as strict as what we had before; for example one apparently can't
add a `Requires:` that refers to an architecture (x86_64 vs noarch).
And a lot more strongly than that we had the repodata checksums
in the old format. I'm still thinking of a way to use those.
But moving on, this allows us to rework the client side to do a lot more
up-front calculation before downloading the jigdoRPM. In the spirit of that, at
the same time let's add a `Provides: rpmostree-jigdo-commit(e7bdb7443d8...)` so
that we can determine ahead of time whether or not we have the actual commit.
A major change we could now take would be to download the jigdoRPM
in parallel with the jigdo set, but doing that would require
driving a lot more of the jigdo logic into the core; it'd need
to know to specially handle the jigdoRPM download.
Closes: #1140
Approved by: jlebon
I was looking at this while chasing what turned out to be an entirely different
bug. Since we're referencing `checksum`, let's call the interator removal last.
Closes: #1140
Approved by: jlebon
The idea is to see how much "waste" there is in downloading the set subtraction
of "installSet - jigdoSet".
At the moment I'm actually seeing e.g. `emacs-filesystem-1:25.3-3.fc27.noarch (0
bytes)` where I expected the download size, but that's a separate bug probably
in libdnf which I'll look at later.
Closes: #1140
Approved by: jlebon
While we do this when writing the final object, let's do it early on
for better security. Was just thinking about this while redoing
how we parse the jigdoRPM.
Closes: #1140
Approved by: jlebon
Having the "jigdo set" in repodata makes it so we can parallel download the
jigdo RPM with the set. However for now, I kept the jigdo set in the jigdoRPM,
since that way it'll be covered by the signature.
Also, this changes the way we inject metadata to use a magic comment string,
since trying to pass a gigantic macro to `rpmbuild` via its argv didn't work out
so well (it looks like rpmbuild eats newlines). This approach is more robust.
Closes: https://github.com/projectatomic/rpm-ostree/issues/1132Closes: #1140
Approved by: jlebon
This is another big task just like importing that greatly benefits
from being parallel. While here I hit the issue that on error
we didn't wait for pending async tasks to complete; I changed things
for importing so that we do that, and used it here too.
This was almost straightforward except I spent a *lot* of time
debugging what turned out to be calling `dnf_package_get_nevra()`
in the worker threads 😢.
I'm mostly writing this to speed up unified core/jigdo, but it's also obviously
relevant on the client side.
Closes: #1137
Approved by: jlebon
Basically since we're doing internal async ops which set the cancellable on
failure, we still want the first error to win since it'll be more useful. See
the docs for `g_task_set_check_cancellable()` for more.
Closes: #1137
Approved by: jlebon
I believe this is a leftover vestige, and it was adding confusion when I was
debugging `rpmostree-core.c` async ops and cancellation.
Now the only cancellables in the daemon are created by transaction ops.
Closes: #1137
Approved by: jlebon
