https://bugzilla.redhat.com/show_bug.cgi?id=2252763 Neal Gompa <ngompa13@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ngompa13@xxxxxxxx | |m) | --- Comment #5 from Neal Gompa <ngompa13@xxxxxxxxx> --- Initial spec review: > # Set explicit conflicts with 'mariadb' packages > %bcond_without conflicts_mariadb > # Provide explicitly the 'community-mysql' names > # 'community-mysql' names are deprecated and to be removed in future Fedora > # but we're leaving them here for compatibility reasons > %bcond_without provides_community_mysql > # Obsolete the package 'community-mysql' and all its sub-packages > %bcond_without obsoletes_community_mysql Do you need these to be conditionals? It makes it confusing to read the spec and I don't know why you wouldn't have these conflicts and obsoletes enabled? Also, in general for bconds, is there a reason you're not using the new style? e.g. "%bcond foo 1" for enabled and "%bcond foo 0" for disabled. This is even supported in RHEL 9. > Provides: bundled(boost) = %{boost_bundled_version} Why is boost bundled? Is there no way to use the system version? > # arm build ends with out of memory error for LTO enabled build > %ifarch %arm > %define _lto_cflags %{nil} > %endif Can you change this to %arm32? That way it's more clear this is about 32-bit ARM and not all ARM architectures. > cmake -B %{_vpath_builddir} -LAH Could you please add a comment that this is about listing all the CMake variables set? It was not immediately obvious to me. > %if %{without clibrary} RPM upstream prefers the usage of "%if ! %{with foo}" over using "%if %{without foo}" From: https://rpm-software-management.github.io/rpm/manual/conditionalbuilds.html "Always test for the with-condition, not the without-counterpart!" -- 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=2252763 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202252763%23c5 -- _______________________________________________ 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