On Sat, Apr 5, 2025 at 8:45 PM Chris Adams <li...@cmadams.net> wrote:
>
> A lot of perl packages (at least) use the macro %{_fixpermss}.  Defined
> in /usr/lib/rpm/macros (from rpm itself), the macro uses chmod.  When
> reviewing a new package of mine, the reviewer said I should BR
> coreutils because of that, which makes sense... although thinking about
> it, should a package really need to do that?  It kind of feels like rpm
> should handle Requires: for anything needed to implement the core set of
> macros, and packages should then expect those macrors to "just work".
> BRing coreutils for that feels like knowing an implementation detail
> that shouldn't be spread across a ton of packages.

From the Packaging Guidelines
https://docs.fedoraproject.org/en-US/packaging-guidelines/#buildrequires:
> You MAY assume that enough of an environment exists for RPM to function, to 
> build packages and execute basic shell scripts, but you SHOULD NOT assume any 
> other packages are present as RPM dependencies and anything brought into the 
> buildroot by the build system can change over time.

and from rpm:
$ rpm -q --requires rpm | grep core
coreutils

So no, I would not say you need a BR on coreutils, because it's a
requirement for RPM to function.

> Either way, there's probably a need to update pacakges... just looking
> at perl SRPMS in rawhide, there's a big split between packages with a
> BR: coreutils and not.  A quick look finds:
>
> - 1726 perl-* packages that BR coreutils
> - 1227 perl-* packages that do NOT BR coreutils but use %{_fixperms)
> - 134 perl-* packages that do NOT BR coreutils, also do NOT use %{_fixperms}
>
> I'd bet the bulk of the 1726 that do BR coreutils are fox %{_fixperms}
> and could drop it, or the 1227 that don't BR coreutils should be updated
> to do so.
>
> I don't know how common %{_fixperms} use is outside of perl packages.
>
> Thoughts?
> --
> Chris Adams <li...@cmadams.net>

-- 
Elliott
-- 
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to