-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version check improvements #32
Conversation
3aa84ef
to
bde5266
Compare
When calling `search_generic()`, the `version` parameter is taken from the output of `cargo metadata`, which always return the latest version available on crates.io. Due to ba11751 this implies the crate will be considered missing from Debian unless the packaged version is the latest one. This commit adds a fallback version check in case the initial check fails, by trimming the version to a supposedly compatible semver version. Fixes kpcyrd#31
Package search only returns a boolean depending on whether a package with a correct version exists in Debian (or NEW). This isn't sufficient to handle the cases where the package exists, but is so outdated that the version in Debian is likely incompatible with the crate we're inspecting. Moreover, this doesn't differentiate between exact version matches and semver'd matches (e.g. when the Debian version is older but has the same major -- and, if needed, minor -- as the version found on crates.io). In order to deal with the latter case, this change introduces the notion of "compatible" version: it represents crates already packaged in Debian but not on the latest version, although it *should* still be compatible with the requirements. The "compatible" and "outdated" information are then propagated, as well as the Debian package version, through a new `db::PkgInfo` structure used as the return type for the `db::search*` functions. That way, this additional information can easily be processed by other modules and ultimately be reported to the user.
bde5266
to
18897d7
Compare
Thanks a lot for your contribution :) I know that there isn't very good test coverage today, but how do you feel about creating a test that showcases this behavior? It feels like this can be subtle enough to easily break by mistake in the future. |
I haven't had time to look into this yet (the last few days both the Reproducible Builds Summit and the Arch Linux Summit kept me quite busy), but I also noticed the current |
Hmm, I came up with the following test: #[test]
fn check_version_reqs() {
let mut db = Connection::new().unwrap();
// Debian bullseye has rust-serde v1.0.106 and shouldn't be updated anymore
let query = "SELECT version::text FROM sources WHERE source in ($1, $2) AND release='bullseye';";
let info = db.search_generic(query, "serde", &Version::parse("1.0.100").unwrap()).unwrap();
assert_eq!(info.status, PkgStatus::Found);
assert_eq!(info.version, "1.0.106");
let info = db.search_generic(query, "serde", &Version::parse("1.0.150").unwrap()).unwrap();
assert_eq!(info.status, PkgStatus::Compatible);
let info = db.search_generic(query, "serde", &Version::parse("2.0.0").unwrap()).unwrap();
assert_eq!(info.status, PkgStatus::Outdated);
let info = db.search_generic(query, "notacrate", &Version::parse("1.0.0").unwrap()).unwrap();
assert_eq!(info.status, PkgStatus::NotFound);
} The thing, it requires network access, so it can work for upstream (this repo), but would have to be patched out for the package to build on Debian's buildd. |
Something I've done in cases like this is: #[test]
#[ignored]
fn check_version_reqs() {
// ...
} Then run both |
@kpcyrd Thanks for the hint! I just pushed the test as a new commit based on that |
73c4ded
to
ea10f1d
Compare
This new test searches for `serde` in Debian Bullseye, which is `oldstable` now and thus won't be updated anymore. It requests various versions to ensure the crate is reported as "found", "outdated" or "compatible" appropriately. It also searches for the non-existing `notacrate` to ensure it properly reports missing packages. Finally, this test (which requires network access) is marked as ignored so it isn't run by default, avoiding issues with Debian's build process. The workflow has been updated to ensure this test is run in CI.
ea10f1d
to
122912d
Compare
Thanks, you now also need to edit
|
Done already, using (unless you prefer to keep those as 2 separate steps?) |
Doing them both in once is fine, I wasn't aware there's an option for that :) |
Thanks for improving the version checking! I had noted in #29 (comment) that there were some side-effects, and hadn't gotten time to work on addressing those. |
This PR addresses 2 distinct "issues":
Those are split in 2 separate commits in case you only want to cherry-pick the first part.