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 won't be any support for writing to the bdb backend in f34, so
e.g. pkglayering won't work (and obviously even composes wouldn't work
once the buildroot moves to f34).
Instead of requiring the whole world to add an `rpmdb` key in their
manifests, let's just add a compile flag for it, and tweak the spec file
to use this flag on f34.
This completes the task of unifying the build of all of our C/C++
into a single unit, which avoids code duplication and will allow
us to more easily use LTO in the future.
These link to librpmostreepriv.la which will be going away.
I think we should basically focus on moving code into Rust which
has a solid solution for this in `#[test]` and debug vs release
builds etc.
A long time ago we de-duplicated the daemon and binary
into a single executable, but left the daemon code
building as an internal static library.
Let's take the next step and compile the sources directly as part
of the executable build. For example, we can then de-duplicate
the `CFLAGS/CXXFLAGS`. And in the future this will help us
turn on LTO.
A long time ago now we started injecting the package list
into the ostree commit.
We were carrying backwards compatibility code to do a checkout
of an ostree commit and extract it, but if we delete that
and have it return an error, it removes the last bits
that end up calling into our internal librpmostreepriv.la.
Now the internal shared library only links to our private `libdnf.so.2`,
`libglnx.la` statically, and libglib.so and libostree.so.
In the future it'd be nice to even drop the linkage to `libdnf.so.2`
because that drags in a lot of stuff, and I suspect e.g. gnome-software
may hit incompatibilities if it also links in the "system" libdnf.
This is a potential path to fix
https://github.com/coreos/rpm-ostree/issues/2391
Basically our shared library and executable duplicate too much
code (particularly Rust). Since most of the shlib APIs aren't
performance sensitive, let's have them fork off the binary
via a hidden CLI entrypoint and parse the output.
We got annobin (hardening) warnings in a downstream RPM analysis,
I think this will help ensure that the Rust code is built with
things like `-znow` etc.
We need this for https://cxx.rs
While we're here:
- Add some more comments/links
- Since the Rust bits are now at the toplevel, we can explicitly
invoke `cargo`
- And since we can do that, use the `+` syntax to specify the
toolchain explicitly
We have logging when a "client" connects to us over the main bus,
but none when a "process" connects to the transaction-private
DBus socket.
It's going to help us debug problems to log the latter. In
the future we can try to correlate them, but for now simple
logging in a similar way should help.
See 82679ce834
I've seen at least one user report a bunch of failing
services on CoreOS that might be due to `/boot` not mounting.
Let's make it explicitly clear this is required.
The error would then be systemd saying a dependency failed, rather
than ostree confusingly saying it can't invoke `readlinkat()`.
Silence is a bit too eerie for this. But what we really
need to do is switch to using cxx-rs so we can pass down the
`Transaction` object into Rust so that we can emit messages
from that side (including things like package diffs).
(Keeping the old name for muscle memory compatibility for now)
I think `apply-live` is a clearer name; it's more imperative
and it may not be obvious (particularly to non-native English speakers)
to parse "livefs" as "live fs".
