rpm-ostree/Cargo.toml

68 lines
1.6 KiB
TOML
Raw Normal View History

[package]
name = "rpmostree-rust"
version = "0.1.0"
authors = ["Colin Walters <walters@verbum.org>", "Jonathan Lebon <jonathan@jlebon.com>"]
edition = "2018"
[dependencies]
anyhow = "1.0.38"
paste = "1.0"
serde = { version = "1.0.123", features = ["derive"] }
serde_derive = "1.0.118"
serde_json = "1.0.61"
serde_yaml = "0.8.15"
libc = "0.2.82"
cxx = "1.0.28"
nix = "0.19.1"
glib-sys = "0.10.1"
glib = "0.10.3"
gio-sys = "0.10.1"
gio = "0.9.1"
ostree = { version = "0.9.1", features = ["v2020_4"] }
ostree-sys = "0.7.1"
tempfile = "3.2.0"
clap = "2.33.3"
structopt = "0.3.21"
openat = "0.1.19"
app: Add `rpm-ostree compose extensions` This adds support for a new `rpm-ostree compose extensions` command` which takes a treefile, a new extensions YAML file, and an OSTree repo and ref. It performs a depsolve and downloads the extensions to a provided output directory. This is intended to replace cosa's `download-extensions`: https://github.com/coreos/coreos-assembler/blob/master/src/download-extensions The input YAML schema matches the one accepted by that script. Some differences from the script: - We have a guaranteed depsolve match and thus can avoid silly issues we've hit in RHCOS (like downloading the wrong `libprotobuf` for `usbguard` -- rhbz#1889694). - We seamlessly re-use the same repos defined in the treefile, whereas the cosa script uses `reposdir=$dir` which doesn't have the same semantics (repo enablement is in that case purely based on the `enabled` flag in those repos, which may be different than what the rpm-ostree compose ran with). - We perform more sanity-checks against the requested extensions, such as whether the extension is already in the base. - We support no-change detection via a state SHA512 file for better integration in cosa and pipelines. - We support a `match-base-evr` key, which forces the extension to have the same EVR as the one from a base package: this is helpful in the case of extensions which complement a base package, esp. those which may not have strong enough reldeps to enforce matching EVRs by depsolve alone (`kernel-headers` is an example of this). - We don't try to organize the RPMs into separate directories by extension because IMO it's not at the right level. Instead, we should work towards higher-level metadata to represent extensions (see https://github.com/openshift/os/issues/409 which is related to this). Closes: #2055
2021-01-12 00:53:05 +03:00
openat-ext = "^0.1.11"
curl = "0.4.34"
rayon = "1.5.0"
c_utf8 = "0.1.0"
rand = "0.8.3"
phf = { version = "0.8", features = ["macros"] }
systemd = "0.8.2"
indicatif = "0.15.0"
lazy_static = "1.4.0"
envsubst = "0.2.0"
subprocess = "0.2.6"
chrono = { version = "0.4.19", features = ["serde"] }
libdnf-sys = { path = "rust/libdnf-sys", version = "0.1.0" }
memfd = "0.3.0"
rust-ini = "0.16.1"
os-release = "0.1.0"
[build-dependencies]
cbindgen = "0.16.0"
anyhow = "1.0"
[lib]
name = "rpmostree_rust"
path = "rust/src/lib.rs"
crate-type = ["staticlib"]
[profile.release]
# Unwinding across FFI boundaries is undefined behavior, and anyways, we're
# [crash-only](https://en.wikipedia.org/wiki/Crash-only_software)
panic = "abort"
# We assume we're being delivered via e.g. RPM which supports split debuginfo
debug = true
# We need this to avoid leaking symbols, see
# https://internals.rust-lang.org/t/rust-staticlibs-and-optimizing-for-size/5746
lto = true
[features]
sqlite-rpmdb-default = []
fedora-integration = []
default = []