#898 %define used in disable a BRP example, why not %global
Closed: Fixed a year ago by ngompa. Opened 2 years ago by churchyard.

Guideline page needing clarification:



The example that disables BRP is:

%define __brp_python_bytecompile %{nil}

Why does it use %define over %global? We say otherwise in https://docs.fedoraproject.org/en-US/packaging-guidelines/#_global_preferred_over_define

I think it is because when RPM does macro expansion. But I'll need to check.

One needs %define is that (and some rare other) particular case, because you need to override some preset rpm macro, that is used outside of the spec file's scope.

%global only takes precedence over things, that are used in the scope of the spec file, e.g. %prep, %build, et all., but it doesn't override macros, which are used inside of rpm's internal processing. For that reason %global is generally prefered over %define. Besides this every %global gets fully expanded before any other part of the spec file (even before the metadata) is parsed, and replaces any use of that %global with the fully expanded result.

%define does the same as %global, with the addition, that it takes precedence over every other previous (and thus even overrides %global) definition of that macro, even the internal ones of rpm. Another side effect of %define is lazy expansion; it behaves pretty similar as match-and-replace regex, where the used %define is literally replaced with the unexpanded contents.


%global foo %(echo 1) ---> Will be expanded before parsing any part of the spec file

if %foo ---> gets replaced with: %if 1, but only in the scope of the spec file

%define foo %(echo 1)

if %foo ---> gets replaced with: %if %(echo 1), and will additional replace any other (even rpm internal or explicit %global inside of the spec file) definition of foo.

Great explanation ... can we close this ticket now, or churchyard do you want some text in the docs. saying why it is used?

Yet it works with both. %global overrides the __brp_python_bytecompile macro just as good as %define.

@churchyard, so can you cleanup those and close this ticket?

Metadata Update from @ignatenkobrain:
- Issue assigned to churchyard

2 years ago

I've asked for clarification: Why does it use %define over %global?

So far I got no valid reason. So the "cleanup" is to replace it with %global?

I've asked for clarification: Why does it use %define over %global?

Well, I think we all agree here that if %global works, it should be used.

So far I got no valid reason. So the "cleanup" is to replace it with %global?


ack. anyone who disagrees, speak up please.

ack. anyone who disagrees, speak up please.

Acking here, with the following exception:

Using %global works in Fedora and RHEL >= 8, thus there must be an alternative guideline for older EPEL packaging.

Alternative guidelines for EPEL are managed in a separate document (https://fedoraproject.org/wiki/EPEL:Packaging) and not by this committee.

That said.... I don't see how the example in question would ever have worked on any release of EPEL, regardless of whether it uses %define or %global. The cleanup and regularization of %__os_install_post and the brp scriptlets wasn't done until well after EL7 was released, and it wasn't backported. As far as I know, you simply can't disable the call to brp-python-bytecompie in EL7 or EL6 without modifying%__os_install_post.

Login to comment on this ticket.

Related Pull Requests
  • #1070 Merged a year ago