https://bugzilla.redhat.com/show_bug.cgi?id=2357473 --- Comment #6 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- Thank you for the review! https://release-monitoring.org/project/377550/ (In reply to Fabio Valentini from comment #5) > The only "blocking" thing that you need to resolve before importing the > package would be to add ExcludeArch for i686, the package doesn't build > there. Good observation. > ============================================================================= > === > > (0. It's a bit funny to see almost 200 lines of "setup" but then have the > actual %build, %install, %check, and %files as essentially just boilerplate. > :)) > > 1. ron 0.9.0 is actually out: > > https://crates.io/crates/ron/0.9.0 > > So this comment is no longer entirely accurate. It's still *somewhat* > accurate, because we don't ship ron 0.9.0 yet, and I don't even know if > 0.9.0-alpha would be compatible with 0.9.0 final - so it mightn't even help > if we did. I had noticed that. It’s on my medium-term TODO list to investigate updating the rust-ron package in Fedora (so I’m not caught unprepared once I start asking for changes upstream), then send a PR to https://github.com/pubgrub-rs/pubgrub/ to update the ron dev-dependency to 0.9.0 final, then ask https://github.com/astral-sh/pubgrub to pull the change into their fork. Once that’s all done, and uv upstream updates the git dependency on the astral pubgrub fork, I’ll finally be able to drop the ron-related patches from uv and python-uv-build. None of that should be too difficult, but it will take a while to work through the whole process. I decided to leave the comment as-was rather than adding a lot of detail about the process of removing the patch. > 2. I don't understand why pep440_rs and pep508_rs being only "passively > maintained" is ... a problem, apparently? Or how they determined that they > even *are* "passively maintained"? > > They have regular releases, and even their other project (astral-sh/ruff) > still depends on them. I agree that the “passively maintained” characterization doesn’t seem to be accurate. On the other hand, I just spot-checked the source diff between src/ in https://github.com/konstin/pep440-rs and uv/crates/uv-pep440/src/ in https://github.com/astral-sh/uv, and the part of upstream’s rationale where they say that the "uv-" implementations “have diverged significantly” from the standalone/crates.io ones does seem to be quite accurate. It’s hard to see the two implementations being reconciled at this point. > 3. This reads a bit like getopt-salad, and I don't claim to understand what > half these flags do: > > > %setup -q -T -D -b 200 -n uv_build-%{version} The flags for using %setup with multiple sources are *awful*. This is basically the recipe in "Using %setup in a Multi-source Spec File" from http://ftp.rpm.org/max-rpm/s1-rpm-inside-macros.html. It’s extracting Source200, resulting in pubgrub-b70cf707aa43f21b32f3a61b8a0889b15032d5c4/ as a sibling of uv_build-0.6.12/ from Source0, and then we end up back inside uv_build-0.6.12/. It would probably be easier to just invoke tar manually, but this works as advertised, and is actually much less fancy than it appears. > > %autopatch -p1 -m200 -M299 This is applying patches numbered 200-299, inclusive. The scheme of numbering extra source archives as 100, 200, 300, and so on, and then numbering patches for those archives as 100-199, 200-299, 300-399, and so on, respectively, is carried over from uv. There, it really helps cut down on confusion about which patches go with which sources. Here, there is only one extra archive, and there is no Source100 because pubgrub/version-ranges is Source200 in uv, and making the numbers match helps avoid unnecessary differences between the two spec files and make it easier to compare them. > 4. I'm assuming there are no "Python" tests, i.e. runnable from pytest (or > similar)? Then just running %cargo_test is fine. Right. > 5. Note that if you ever want to build this crate for old branches (like > EPEL 9), you will need to "export RUSTFLAGS=%{build_rustflags}" or similar, > because %set_build_flags only sets RUSTFLAGS on recent branches of Fedora > (and I think in EPEL 10, but I'm not even sure about that). Checking EPEL 10, I don’t see RUSTFLAGS in the expansion of %set_build_flags, but in a test build, I neverthless do see it getting set in %build. This will still be something to remember if we ever manage to branch maturin in EPEL 9. > 6. You might need to add "ExcludeArch: %{ix86}" to this package. I launched > a scratch build, and it failed on i686. Good catch. The original uv submission had a patch to build on i686, but it was removed based on review feedback (basically: why bother?). I guess it would make sense to start out with ExcludeArch here, although it seems like every time I try to exclude i686 in a Python library package, I’m painted into a corner by shifting dependencies and I end up restoring i686 support later. Hopefully that doesn’t happen here. I would rather not build an i686 package if I don’t have to. > 7. There's duplicate files warning from rpmlint, but that is probably > unavoidable (license files bundled in pep440_rs and pep508_rs being > identical). But it would be good to address the duplicates mentioned by Miro > in the previous comment. I still think that it is weird to have a /usr/share/licenses/python3-uv-build/ that contains the licenses for bundled libraries and statically-linked dependencies, but *not* the licenses for the package itself. Still, I’ll defer to the two votes in favor of omitting the duplicates. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2357473 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202357473%23c6 -- _______________________________________________ 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
