https://bugzilla.redhat.com/show_bug.cgi?id=2299712 --- Comment #6 from Miro Hrončok <mhroncok@xxxxxxxxxx> --- (In reply to Ben Beasley from comment #2) > (In reply to Miro Hrončok from comment #1) > > The Licenses in the comment and in the License tag seem to be represented > > differently. See e.g. "Zlib OR Apache-2.0 OR MIT" vs "Apache-2.0 OR MIT OR > > Zlib" -- this is confusing and hard to verify. > > I ordered the components of disjunctive license expressions alphabetically > because in very many cases, there are differently-ordered equivalent > versions among the statically linked crate dependencies. For example, the > raw %{cargo_license_summary} output contains all of the following: > > # MIT OR Apache-2.0 OR Zlib > # MIT OR Zlib OR Apache-2.0 > # Zlib OR Apache-2.0 OR MIT > > It’s hard to deduplicate these, or quickly check if a combination of > licenses already exits in the License expression, without applying some sort > of consistent normalization. It’s also kind of aesthetically displeasing to > have to choose one form over the other two with no particular rationale. > > I’m open to other approaches, but I’m also also mindful of the need to > cross-check and update the License expression when updating the package, > without having to go through every part of it from scratch. How would you > prefer to write the License expression? I'll think about it. > > > %package -n python3-uv > > > Summary: %{summary} > > > > This subpackage should have a different summary. > > How about this? > > Summary: Importable Python module for uv +1 (In reply to Fabio Valentini from comment #4) > > > > export RUSTFLAGS='%{build_rustflags}' > > > > > > This should be part of %set_build_flags, is it actually needed? > > > Hmm, it doesn’t look like it. Perhaps I copied that thoughtlessly from something else, or perhaps I did it in anticipation of possibly backporting to EPEL9 where %set_build_flags is not automatic – but I can cross that bridge when and if I get there. > > RUSTFLAGS are only part of %set_build_flags on newer Fedora branches. I > don't quite remember if it's F40+ or F39+ ... so it's necessary for older > branches (and just redundant on newer branches). F39+ but it is necessary on EPEL9 (which does not have automatic %set_build_flags and dos not seem to have RUSATFLAGS in %set_build_flags). (In reply to Yaakov Selkowitz from comment #3) > Are emoji in the spec file even acceptable (iow might they break something)? As with any Unicode symbols, they are acceptable. A bit unorthodox, but definitively acceptable. (In reply to Fabio Valentini from comment #5) > Side note: > > Maybe just drop ", written in Rust" from the Summary. That's arguably an > implementation detail and not really useful in the Summary That's how upstream presents itself. I'd keep it. (It's probably not allowed to write a tool in Rust without saying "written in Rust" in the description :D) -- 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=2299712 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202299712%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
