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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In the case of client layering, we hackily use the treespec because
that's what the core understands (for now), but it really shouldn't be
part of the final commit, nor should we rely on it.
This patch starts the path towards moving us away from the treespec by
not embedding it in client layers, and instead directly inserting
layered packages under the "rpmostree.packages" key.
The SERVER_BASE case still embeds the treespec, since only the container
path uses it for now and it needs it.
Down the line, we'll want to make the treespec just one of the methods
by which we initialize RpmOstreeContext. But nothing stops us from
hiding that detail already.
Closes: #650
Approved by: cgwalters
We don't want to expose the host's `/tmp` since that means scripts could
potentially find things like the X11 socket or whatever.
To debug things better, add a quick bash script to run bwrap like the C code
does. Perhaps down the line we can add `rpm-ostree internals run-bwrap` or so.
Closes: #647
Approved by: jlebon
This is the culmination of the work paved by the previous commits. We no
longer handle package set mutations in the upgrader, but rather let
clients modify the origin as needed for that. As such, the upgrader is
now completely memoryless. We no longer try to error out if a package is
already in the base and we no longer drop out packages previously
layered packages that are now in the base. *Which* packages actually get
layered is determined during deployment and not coded in the origin.
At an API level, the deployment variant returned (and thus what gets
printed by `status --json`) now has both "packages" and
"requested-packages". The former retains its original semantic: it's the
set of packages that are *actually* layered. The latter contains
everything from the origin, which includes the former set + dormant
packages.
Accordingly, the output of `rpm-ostree status` also now distinguishes
between "RequestedPackages" and "LayeredPackages". Extra: we now quote
provides that contain spaces.
Closes: #646
Approved by: cgwalters
Ideally, we want to parse out everything in the origin on init and then
cache the values to make it even easier to inspect it. We make this more
explicit by renaming the struct members to "cache_*" and also caching
the initramfs args. This doesn't actually save any allocations right
now (though it might in the future), but we do the same for everything
else, and it's nice to be consistent.
Closes: #646
Approved by: cgwalters
There are multiple reasons for this. The first is that with the
introduction of "dormant" packages, it becomes impossible from simply
looking at a deployment's origin whether it was layered or not. We
*could* make the upgrader turn around and insert back the "real" final
packages that were layered. But we're really trying to reinforce the
concept that the origin is mutable and represents an input for the
upgrader. Derived data shouldn't live there.
Whether a deployment is actually layered or not instead is determined by
the deployment commit itself. The embedded treespec records the exact
packages that were layered, which we will later use to enhance status
output.
Closes: #646
Approved by: cgwalters
There are two main issues right now; first, we don't pick up manual changes to
`.origin` files, which occurs when one needs to sed it to remove `unconfigured`
for example. Second, we need to reload changes to the remotes.
Closes: #598
Approved by: jlebon
Clean up the output of vmcheck a bit by printing out ssh debug details
and rpm-ostree status output to the log file. This will help make it
easier to quickly see which tests failed (as well as helping satisfy my
OCD for a nice output).
Closes: #645
Approved by: cgwalters
On the first call to vmsync/vmoverlay, we do an immediate vm_ssh_wait()
to check if we have a live VM. However, we don't necessarily have a
working rpm-ostree in there if we're hacking on stuff. It gets annoying
to wait for the timeout there.
Let's just work around that by instead only calling status if we got
there through vm_reboot_cmd(), which is most likely when we're most
interested in the status output anyway.
Closes: #645
Approved by: cgwalters
This is a follow-up to 775c781 (#626). Really, RpmOstreeOrigin shouldn't
concern itself with whether the origin is unconfigured. Its main goal
should be to parse it out and make it easy for users to modify it. That
sort of business logic lives in the upgrader, which *should* be
concerned if the origin in unconfigured.
Closes: #634
Approved by: cgwalters
This is the beginning of a move towards making the upgrader more
stateless and less hysteretic. Ideally, the only input required should
be an origin file. Users of the upgrader are in charge of modifying the
origin as needed. The main goal of this is to simplify the upgrader
model and a better separation of concerns.
This was already done for the initramfs-related entries. This patch
formalises this for most of the other inputs, except packages, which
will be done soon.
Closes: #634
Approved by: cgwalters
This functionality is disabled right now, and if we want to re-enable
it, we'll want to do it in a way that ensures the ignore scripts are
permanent.
Closes: #634
Approved by: cgwalters
Let's not hardcode a broken English-only version of `ngettext` here; rework the
message to avoid requiring pluralization.
Closes: #632
Approved by: jlebon
nchange_date, nchange_name, and nchange_text are declared in a larger
scope in rpmostree-rpm-util.c. Reduce the scope to satisfy cppcheck.
Closes: #628
Approved by: jlebon
See https://github.com/projectatomic/rpm-ostree/issues/233 - for RPMs which
place files in e.g. `/opt`, we have different behavior in the treecompose case
(silently drop it) versus package layering (does the wrong thing).
Since the unpacker right now is only used in the layering case, this just
ensures we'll get a consistent error there.
Closes: #624
Approved by: jlebon
As part of an earlier cleanup of origin parsing, we started checking
the origin `unconfigured-state` even just starting the daemon, which
is kind of bad.
It's tempting to flip the default for the parser so that we *only* check
unconfigured state if we go to upgrade, but let's not do that in this patch.
Closes: #626
Approved by: jlebon
The hash tables are only initialized if the initable init completes, but it
won't if something goes wrong there. In this case, an origin
`unconfigured-state`.
Closes: #626
Approved by: jlebon
I'm not sure why we weren't doing this before, but we need to also
support files in /var and /run that are owned by root.
Related: RHBZ#1421781
Closes: #622
Approved by: cgwalters
We sometimes talk about using `ostree admin undeploy`, but that
doesn't know about the pkgcache, and hence space there leaks
until the next rpm-ostree operation.
Just for this, we need to expose a cleanup command (and API). But
we also need to support cleaning:
- repomd
- downloads (repo/tmp)
So let's start implementing that.
Closes: #614
Approved by: jlebon
This patch makes the diff outputs generated by deploy commands (like
upgrade/deploy/rebase) and db diff commands the same. They were both
tweaked in different ways. The former gained the ability to discern
between upgrades and downgrades, the latter gained the ability the print
package version transitions.
Of course, the best way to make them the same would be to make them use
the same code, though I'm not sure it's worth the pain to gain ratio at
this point...
Closes: #575Closes: #619
Approved by: cgwalters
I debated just putting this in the supported list, but decided against
it in the end. This really should be something that happens
transparently, and if it doesn't then something else is probably wrong.
Closes: #617
Approved by: cgwalters
This doesn't look like it actually does anything... Though I haven't
checked the history to see if it used to and it somehow got nixed by
accident.
Closes: #615
Approved by: cgwalters
We weren't exiting the intended way before because we were tripping an
assertion:
GLib-CRITICAL **: g_main_loop_quit: assertion 'loop != NULL' failed
This was because the global loop was being shadowed by a local variable.
Closes: #612
Approved by: cgwalters
Until now, we always used the booted deployment, and would
garbage collect the "pending" deployment. This is the
way OSTree was designed, but I think for rpm-ostree given
how mutable we are on the client side, there's a much stronger
argument for being more stateful too.
This is a relatively simple code change to split the "merge deployment"
concept into two. There's now the "config merge deployment" and the
"origin merge deployment".
Basically, `rpm-ostree install foo; rpm-ostree install bar` will
now install both `foo` and `bar`. But we will still use the booted
deployment for `/etc`.
Down the line, I think I'd like to drive into OSTree the concept of
a "staged" deployment, that has the hardlink checkout done, but doesn't
have the config merge.
But we don't need to change the OSTree core for this yet; we can
do it here in rpm-ostree, and this relatively simple code change
fixes many issues at once.
For example, `rpm-ostree upgrade && rpm-ostree install foo` now
does what you expect as well.
Obviously, we want to enable doing multiple things in *one* transaction,
and we're not far away, but I think this is also the right thing to do now.
I'm relatively confident it won't break anyone's workflow, as what
we did before wasn't generally that useful. However, people will
need to learn to `ostree admin undeploy 0` if they *don't* want
this behavior. (We need to have `rpm-ostree cleanup`).
Closes: https://github.com/projectatomic/rpm-ostree/issues/406Closes: #611
Approved by: jlebon
I'm watching https://github.com/rpm-software-management/libdnf/pull/199 and I
really don't like it. We already have a place to put out-of-rpmdb metadata,
which is in the ostree commit for imported packages. No need to involve a
relational database for this (and further, one that would need to learn about
multiple ostrees).
We're not yet *using* this information in the UI, but we could; imagine
changing the `status` `Packages:` to show packages-per-repo or so. We
could also expose an `rpm-ostree pkg-info foo`.
But for now, let's just start recording this.
Closes: #610
Approved by: jlebon
One thing that's very confusing about OSTree is there are two layers -
deployments and the refs/commits. If one does an `rpm-ostree upgrade`, but then
e.g. `ostree admin undeploy 0`, you still have the new revision in the repo.
We don't do a good job of displaying this state, or helping people clean
it up.
Down the line, I also want to better support something like `rpm-ostree pull` to
cache updates explicitly *without* deploying.
This commit just adds a bit of information to the status display. We might want
to have better formatting, but I think this an OK start.
Closes: #595
Approved by: jlebon
We want people to use the libostree API for things like this. Further, the
`rpm-sign` tool that this calls is Red Hat internal, so it doesn't make sense to
have a public wrapper for it.
Closes: https://github.com/projectatomic/rpm-ostree/pull/152Closes: #607
Approved by: jlebon
The actual problem I am trying to fix with this is fallout from the
introduction of `/usr/libexec/rpm-ostreed`, which required a SELinux
policy change. Specifically for CentOS, the base policy is rev'd
slowly.
My hope was that by merging the daemon code back into `/usr/bin/rpm-ostree`
which is labeled `install_exec_t`, starting via systemd would do
the right thing. It turns out that doesn't happen.
Now later, I'm picking this patch back up because I want to do multprocessing in
the daemon (and in the core), and it makes sense to share code between them,
because multiprocessing will need to go through a re-exec path.
Another benefit is we avoid duplicated text (libglnx, internal helpers) between
the two binaries.
Closes: #292
Approved by: jlebon
In particular, I want to start using the repo timestamp as a poor man's
versioning. Knowing when the last time a repo was updated is pretty important if
you're potentially expecting security updates for example.
(I plan to also do something like this on the client side, but let's do it here
first since we already dump lots of crud to stdout. Client side would require
structure/design/thought)
Closes: #604
Approved by: jlebon
