#907 Which %__foo macros for executables are acceptable?
Opened 2 years ago by tibbs. Modified 2 months ago

I just pushed a fix to change the macros section (https://docs.fedoraproject.org/en-US/packaging-guidelines/#_macros) to not say that %__python is OK. (I changed it to say %__python3 is OK.)

However, I've never really understood why it's OK or even ever required to reference %__perl and %__python{2,3}. There was some recent talk on the devel list about some of these macros being nuked with Panu saying that at least some of them were never intended for use directly in specs anyway. The ones discussed were already banned by our guidelines anyway, but since I touched this I figure I might as well ask.

Personally I've always thought that the double-underscored macros are things that you shouldn't be using unless you know what you're doing, and that if we do expect people to use some macro for the perl or python interpreter then we should give them one like %perl or %python. And with those various macros being removed from core RPM now anyway, it's a good time to think about providing something better.

Metadata Update from @james:
- Issue tagged with: meeting

2 years ago

To recap what I said on devel, the double-underscored helpers basically exist to allow changing macro or rpm behavior without recompiling. So generally speaking, the two legitimate use-cases for them are
1) to redefine to something else
2) to use specifically the same utility that rpm (or some macro) uses

2) matters every now and then, but in reality many of the existing %__foo macros aren't used by rpm anywhere at all, they're just historical cruft. The %__auto* macros had a justification as long as they were used by %GNUconfigure but that went out long ago.

So "only use double-underscored macros to redefine, or there's a concrete need to do so" is a fair starting point. "Because it's there" is not a reason. And yes, macros intended for direct use shouldn't have any leading underscores, that's a good guideline for new macro additions, and one that most Fedora macros in eg redhat-rpm-config already adhere to.

@corsepiu is a big fan of %__ macros (see e.g. rpms/perl-Plack). As far as I remember, he claimed that he wants to call the tools by an absolute path because he has non-distribution tools in PATH and that helps him to build Fedora packages locally. Maybe he could elaborate more or correct my memory.

Personally, I don't have any use for that macros. If you agree to demote them, feel free to remove %__perl from examples in Perl guidelines.

I guess the problem is articulating the concrete need for doing this. Certainly most of the uses today are purely because of cargo cult behavior.

Let's look at where double-underscored things are used in the guidelines:

  • Various uses of %__requires_exclude and %__provides_exclude (plus the related _from variables) which are all definitions and valid in any case.
  • %__find_provides and %__find_requires in the Drupal, Octave and OCaml guidelines which... really should be done in rpm or redhat-rpm-config and not in individual specfiles. Anyway, they're still valid but we should check if we can remove any need to use them.
  • The main guidelines talk about setting %__bootstrap which is valid.
  • The %__uid_u macro is mentioned in a few places, to specify BuildRoot: tags. I will clean these up.
  • The Lisp guidelines have %{__rm} -rf %{buildroot}. Ugh. I will clean this up, too.
  • The Meson guidelines reference %__meson. Says it's rare though permissible to call it. Might need a tweak.
  • The Node.js guidelines suggest the use of %__nodejs to call the interpreter.
  • Various uses in the Perl guidelines which would need work.
  • Lots of uses in the PHP guidelines. Would certainly need work but I expect might also generate controversy.
  • The Python guidelines use%__python3, which will need work.

@tibbs yeah, I think we need to cleanup meson, python, perl, nodejs, but it might be not that easy as it sounds. It leaked into the RHEL so people really use them across the globe.

Not to mention rpmdev-newspec perl-foo generates a spec file template like this:

Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
# Remove OPTIMIZE=... from noarch packages (unneeded)
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS"

We briefly talked about this at last weeks meeting:


  • #907 Which %__foo macros for executables are acceptable? (geppetto,

We talked about this issue this week:


  • we should revisit our use of %__* macros in the guidelines, at least (possibly removing it where appropriate)

As noted in https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/27#comment-30941, the discussed "%__foo to set (a path), %foo to get", is absolutely spot-on.

Thank you all for coming up with such a clear, concise rule.

I wanted to change the Python guidelines to replace %__python3 with %python3 (and %__python2 with %python2). The only remaining issue is that %python is undefined. I think the following behavior would be reasoanble:

  • when user redefines %__python, %python gets defined to the same value
  • when user doesn't redefine %__python, %python is undefined

I don't think that's possible, is it? Possibly could be workarounded by:

  • %python is defined as %__python, but will error if it is /usr/bin/python

We discussed this at this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2019-11-21/fpc.2019-11-21-17.00.txt):

  • #907 Which %__foo macros for executables are acceptable? (mhroncok,
  • The workaround for %python is possible, mhroncok and ignatenkobrain
    will work on it (mhroncok, 17:50:26)

Metadata Update from @tibbs:
- Issue assigned to tibbs

4 months ago

Since we added the toolchain macro to redhat-rpm-config[1], we've been suggesting packages use the __cc, __cxx, and __cpp macros if they want to easily switch between compilers. Should we continue to recommend this or should we add equivalent macros without the underscores and tell maintainers to use those?

[1] https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/macros#_29

Login to comment on this ticket.