https://bugzilla.redhat.com/show_bug.cgi?id=2312901 --- Comment #11 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- Thanks for looking at this! (In reply to Cristian Le from comment #10) > The `data` folder can be removed, couldn't it? The Copying file indicates it > is for benchmarks, and it would be nice to not have to update the license > metadata because of those files. Ugh, I’m not sure how I missed that. The benchmark data are dubiously licensed even for the source RPMs. I sent a PR upstream to python-cramjam for this, https://github.com/milesgranger/cramjam/issues/178. I’ll need to do something similar here, and (until it’s merged and released), package from a “filtered” version of the crate archive to avoid including the dubious files in source RPMs. > Other than that, probably `environment.yml` > can also be excluded from installation. Sure, it’s a tiny file that’s doing no harm, but it’s indeed unnecessary. I would be inclined not to bother patching downstream for it, but it’s worth excluding it in the PR I send upstream for the benchmark data. > I guess you've already discussed > with Fabio about the crate version decoupling for this? I assume you are talking about this? # * Do not test that the blosc2-sys bidings were generated against the exact # version of c-blosc2 that upstream expects; we always use the system blosc2, # whatever that may be. %cargo_test -- -- --exact --skip tests::test_get_version_string I think it did come up explicitly in this case, but in general, loosening bounds on library versions in -sys crates is really our only option. If we are going to build against system libraries, we can’t be pinning them to an exact patch-release. If we really needed an exact patch-release, that would be adequate justification for bundling. In almost all cases these strict dependencies are a matter of the crate authors focusing primarily on static linking with bundled libraries and expecting to control their dependency versions. If an update is ABI-compatible for C programs, it’s very unlikely that it would break a -sys crate. This is even more true in cases like this where I will maintain the -sys crate but not the system library, so an exact-version pin could be broken by a compatible update at any time. Still, I think expecting an exact library version is generally too brittle even when both packages share maintainers. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2312901 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202312901%23c11 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
