lockfile: Switch to writing it from Rust
I wanted to modify the lockfile specification, but then remembered that
it currently lives in two places right now: once on the Rust side where
it's deserialized, and once more on the C side where it's serialized.
If we could write the lockfile from the Rust side, then we wouldn't have
to deal with the `GVariantBuild` and `json-glib` goop, and instead
we could consistently use serde against the same struct for both
serialization and deserialization.
But there isn't an easy way to do this given that the state to be
serialized is intrinsically linked to libdnf.
So this patch takes the next step in our oxidation process by adding a
minimal `libdnf_sys` module which allows us to call `libdnf` functions
from Rust. This is not the prettiest code I've written, and there's
definitely some polishing that could be done. But I think overall it's a
move in the right general direction: as we oxidize more things, we'll at
some point *have* to integrate more tightly with the C side in a
bidirectional way, instead of the "one-way" approach we've been using so
far.
For this patch specifically, in exchange we get a unique source of truth
for the lockfile spec, just like the treefile, and we drop a lot of C
code in the process.
Closes: #1867
Approved by: cgwalters
2019-07-10 16:36:45 +03:00
/*
* Copyright ( C ) 2019 Red Hat , Inc .
*
2019-09-05 17:52:38 +03:00
* SPDX - License - Identifier : Apache - 2.0 OR MIT
lockfile: Switch to writing it from Rust
I wanted to modify the lockfile specification, but then remembered that
it currently lives in two places right now: once on the Rust side where
it's deserialized, and once more on the C side where it's serialized.
If we could write the lockfile from the Rust side, then we wouldn't have
to deal with the `GVariantBuild` and `json-glib` goop, and instead
we could consistently use serde against the same struct for both
serialization and deserialization.
But there isn't an easy way to do this given that the state to be
serialized is intrinsically linked to libdnf.
So this patch takes the next step in our oxidation process by adding a
minimal `libdnf_sys` module which allows us to call `libdnf` functions
from Rust. This is not the prettiest code I've written, and there's
definitely some polishing that could be done. But I think overall it's a
move in the right general direction: as we oxidize more things, we'll at
some point *have* to integrate more tightly with the C side in a
bidirectional way, instead of the "one-way" approach we've been using so
far.
For this patch specifically, in exchange we get a unique source of truth
for the lockfile spec, just like the treefile, and we drop a lot of C
code in the process.
Closes: #1867
Approved by: cgwalters
2019-07-10 16:36:45 +03:00
* /
use libc ;
use glib_sys ;
/* This is an experiment in calling libdnf functions from Rust. Really, it'd be more sustainable to
* generate a " libdnf-sys " from SWIG ( though it doesn ' t look like that ' s supported yet
* https ://github.com/swig/swig/issues/1468) or at least `bindgen` for the strict C parts of the
* API . For now , I just took the shortcut of manually defining a tiny subset we care about . * /
#[ repr(C) ]
pub ( crate ) struct DnfPackage ( libc ::c_void ) ;
2019-11-11 16:50:58 +03:00
#[ repr(C) ]
pub ( crate ) struct DnfRepo ( libc ::c_void ) ;
lockfile: Switch to writing it from Rust
I wanted to modify the lockfile specification, but then remembered that
it currently lives in two places right now: once on the Rust side where
it's deserialized, and once more on the C side where it's serialized.
If we could write the lockfile from the Rust side, then we wouldn't have
to deal with the `GVariantBuild` and `json-glib` goop, and instead
we could consistently use serde against the same struct for both
serialization and deserialization.
But there isn't an easy way to do this given that the state to be
serialized is intrinsically linked to libdnf.
So this patch takes the next step in our oxidation process by adding a
minimal `libdnf_sys` module which allows us to call `libdnf` functions
from Rust. This is not the prettiest code I've written, and there's
definitely some polishing that could be done. But I think overall it's a
move in the right general direction: as we oxidize more things, we'll at
some point *have* to integrate more tightly with the C side in a
bidirectional way, instead of the "one-way" approach we've been using so
far.
For this patch specifically, in exchange we get a unique source of truth
for the lockfile spec, just like the treefile, and we drop a lot of C
code in the process.
Closes: #1867
Approved by: cgwalters
2019-07-10 16:36:45 +03:00
#[ allow(dead_code) ]
extern {
pub ( crate ) fn dnf_package_get_nevra ( package : * mut DnfPackage ) -> * const libc ::c_char ;
2019-07-10 16:50:30 +03:00
pub ( crate ) fn dnf_package_get_name ( package : * mut DnfPackage ) -> * const libc ::c_char ;
pub ( crate ) fn dnf_package_get_evr ( package : * mut DnfPackage ) -> * const libc ::c_char ;
pub ( crate ) fn dnf_package_get_arch ( package : * mut DnfPackage ) -> * const libc ::c_char ;
2019-11-11 16:50:58 +03:00
pub ( crate ) fn dnf_repo_get_id ( repo : * mut DnfRepo ) -> * const libc ::c_char ;
pub ( crate ) fn dnf_repo_get_timestamp_generated ( repo : * mut DnfRepo ) -> u64 ;
lockfile: Switch to writing it from Rust
I wanted to modify the lockfile specification, but then remembered that
it currently lives in two places right now: once on the Rust side where
it's deserialized, and once more on the C side where it's serialized.
If we could write the lockfile from the Rust side, then we wouldn't have
to deal with the `GVariantBuild` and `json-glib` goop, and instead
we could consistently use serde against the same struct for both
serialization and deserialization.
But there isn't an easy way to do this given that the state to be
serialized is intrinsically linked to libdnf.
So this patch takes the next step in our oxidation process by adding a
minimal `libdnf_sys` module which allows us to call `libdnf` functions
from Rust. This is not the prettiest code I've written, and there's
definitely some polishing that could be done. But I think overall it's a
move in the right general direction: as we oxidize more things, we'll at
some point *have* to integrate more tightly with the C side in a
bidirectional way, instead of the "one-way" approach we've been using so
far.
For this patch specifically, in exchange we get a unique source of truth
for the lockfile spec, just like the treefile, and we drop a lot of C
code in the process.
Closes: #1867
Approved by: cgwalters
2019-07-10 16:36:45 +03:00
}
/* And some helper rpm-ostree C functions to deal with libdnf stuff. These are prime candidates for
* oxidation since it makes e . g . interacting with strings less efficient . * /
extern {
pub ( crate ) fn rpmostree_get_repodata_chksum_repr ( package : * mut DnfPackage , chksum : * mut * mut libc ::c_char , gerror : * mut * mut glib_sys ::GError ) -> libc ::c_int ;
}