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))
…
%build
# Remove OPTIMIZE=... from noarch packages (unneeded)
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS"
%make_build
…

We talked about this ticket in this weeks meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2019-07-25/fpc.2019-07-25-16.00.txt

See also https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/27

We briefly talked about this at last weeks meeting:

https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2019-08-01/fpc.2019-08-01-16.00.txt

• #907 Which %__foo macros for executables are acceptable? (geppetto,
  16:23:45)

We talked about this issue this week:

https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-26/fpc.2019-09-26-16.00.html

• 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,
  17:44:21)
• The workaround for %python is possible, mhroncok and ignatenkobrain
  will work on it (mhroncok, 17:50:26)

https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/35

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

Can this issue be closed, or was there something else that you wanted the FPC to discuss/decide? I'm moving the issue to needinfo because nothing has really happened in months, but it might be better to just close and reference it in a new issue if you have follow on questions/requests.