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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
There's a huge difference between live updates that change
existing things, versus simply adding new packages (files).
The latter is really quite safe, and live layering is one
of the most requested features.
In prep for adding more methods, require the caller to identify
themselves.
For now this is `CliClient` - one could imagine in the future
we actually do direct DBus, but there's a whole other world
of stuff there.
Add more metadata that zincati needs, like `base-commit-meta`
which includes the `fedora-coreos.stream` key and the cosa basearch,
etc.
Also `Derive(Debug)` since it's used in a cache struct that also
derives debug, and that's a friendly thing to do in general.
This adds sufficient infrastructure to fully port the
`rpmostree-builtin-applylive.cxx` client code to Rust.
We just keep a stub entrypoint for now until we port
the rest of `rpmostree-builtin-ex.cxx`, at which point
a lot of C++ files go away.
The "finish" bits move from the daemon-oriented `live.rs`
into a new `rust/src/builtins` directory. I'd like
to try to more cleanly split up the Rust sources along
core(shared)/client/daemon directories in the future.
This stubs out sufficient infrastructure for us to register
as a client and call the Moo API.
A glaring problem here is the lack of extensive `glib::Variant`
bindings; that's covered in the next gtk-rs release.
My real goal was to try porting the `rpmostree-builtin-apply-live.cxx`
code entirely to Rust, but there's more to do to expose the
transaction helper APIs we have.
cxx-rs only supports a few basic types in `Vec<T>`/`CxxVector<T>`
and we need to pass an array of GObjects in a few cases.
Add a wrapper class hack instead of using `u64` so we at least
have some basic safety here and have a convenient place to
grep for later when we want to improve this.
This moves the `ror_lockfile_write` to cxx.rs, which brings us closer to
getting rid of cbindgen now.
There's one massive hack this uses, which is that we pass an array of
pointers to `DnfPackage` and `DnfRepo` objects as u64. We'll want to
circle back and fix that up once either cxx.rs supports natively arrays
of pointers, or we just come up with our own wrapper type for it.
But for now at least, this unblocks the cbindgen transition and hacking
on the lockfile code.
Came out of discussion in https://github.com/coreos/rpm-ostree/pull/2581
around some racy code for checking for the live commit object.
The reliability of apply-live depends on the
underlying commits not being garbage collected. Our diff logic
is in terms of ostree commits, not the physical filesystem (this
allows us to make various optimizations too).
Ultimately I think we should drive some of the live-apply
logic into libostree itself; we can more easily have an atomic
state file instead of the two split refs.
(Or perhaps what we should add to ostree is like a refs.d model
where a single atomic file can refer to multiple commits)
For now though let's rework the code here to write refs. We
retain the file in `/run` as just a "stamp file" that signals
that a deployment has had `apply-live` run.
More prep for https://github.com/coreos/rpm-ostree/pull/2388
This was actually also my first time really trying out the
latest gtk-rs `glib::Variant` API, which is one of the major
things we need to use to progress oxidation more.
This moves passwd/group compose preparation logic to Rust,
dropping all the remaining minor helpers related to JSON parsing,
file stream creation, and entries deduplication.
We should really have safety comments around our use of `.unwrap()`.
This Google kubernetes rpm-md repo appears to use seconds-since-epoch.
We could try to detect that, probably best done in libdnf.
I think it'd be better to get them to match the informal schema
for this actually though instead.
For now let's just log an error and not crash.
Closes: https://github.com/coreos/rpm-ostree/issues/2600
It turns out we accidentally added GPL'd code into the Rust
side, which wasn't intentional on my part and I think it's since
been copied around.
Honestly I think half of the problem is the gigantic
"blah blah blah GNU General blah blah" just makes people's eyes
glaze over. In contrast the `SPDX-License-Identifier` is short
and obvious.
So let's validate that in CI.
This follows a similar change in ostree:
https://github.com/ostreedev/ostree/pull/1439
If we merge this I'll do the C/C++ side too after that.
A lot of our output is outside of a "task"; the Rust binding
incorrectly made it a method on `Progress`. This is really
just a `println!()` that is backed by our dispatch system.
When we started using cxxrs, most of the glib-rs objects like
`OstreeRepo`/`OstreeSysroot` were owned by C++ and passed
down into Rust. That motivated the addition of the special
bridging infrastructure to re-create a glib-rs wrapper
type from what cxxrs wants (a `Pin<&mut T>`).
But now that we're adding more in Rust, we have the need
to pass these objects back into C++. In fact this will
hopefully soon because the default case as more of the
binary entrypoint becomes Rust.
Add another trait with a method `gobj_rewrap()` that converts
in the other direction. This implementation took me a number
of tries before I finally settled on simply using `mem::transmute()`.
There are a *lot* of caveats listed on the docs for that function,
but I think it really is what we want here. See the link for pending work
on a Rust RFC to enable safe transmutes for some cases, and I believe
that would cover this use case:
https://internals.rust-lang.org/t/pre-rfc-v2-safe-transmute/11431
I've verified this works in a separate patch, but this commit
also adds a simple test case - this goes all the way from:
Rust glib-rs `ostree::Repo` (holding strong ref)
-> Rust `Pin<&mut ostree_sys::OstreeRepo>`
-> (internal cxx-rs C bridge)
-> C++ `OstreeRepo&` reference
-> C `OstreeRepo*` pointer
Which is quite the dance if you think about it!
clippy complains about `to_*` not taking `&self` - I think
we can simplify this more by using our `write_file_with()` API
that we're using in other places. It was explicitly designed
with serde in mind. It's just more efficient and nicer to
serialize to a `BufWriter` instead of to a string, then
writing the string.
Specifically motivated by adding some docs in `treefile.rs` around
how to add a field, but I decided to just do a pass and
document everything at least a little.
View with e.g. `cargo doc --document-private-items`.
Pretty straightforward. Haven't moved `ror_lockfile_write` yet because
that's trickier to do and I'm still figuring out the most elegant way to
do this within cxx.rs' constraints.
Right now, we're using libdnf APIs from Rust via hand-crafted `extern C`
interfaces, which is extra dangerous because there is no signature
checking that happens at compile-time.
Until either we can automate libdnf bindings or use its C++ API directly
via cxx.rs, let's do some basic wrapping in C++ ourselves and use libdnf
through that API only instead. That gives us a lot more confidence and
makes the libdnf API feel more natural to use in Rust.
We trigger a librpm macro file load in many of our paths. Since the
default value shipped by rpm's macro file sets `_dbpath` to
`/var/lib/rpm`, we have to explicitly set that back to `/usr/share/rpm`
in those paths.
This became more problematic recently with libsolv v0.7.17 which fully
keys off of `_dbpath` to find the rpmdb path to load:
04d4d036b2
And it's not technically wrong; we really should make that macro not
lie. This is what this patch does by injecting an RPM macro file in our
composes which sets it to /usr/share/rpm. So then e.g. the `rpm` CLI
doesn't actually need the `/var/lib/rpm` backcompat link anymore, though
there's no harm in leaving it.
In the future, we should be able to drop this once we move all of Fedora
to `/usr/lib/sysimage/rpm` (see
https://github.com/coreos/fedora-coreos-tracker/issues/639).
Closes: #2548
