[Fedora-packaging] %{_libdir}/rpm/brp-compress for perl modules

[Ville Skyttä]

On Tue, 2005-03-29 at 11:07 -1000, Warren Togami wrote:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127988
> 
> [ -x %{_libdir}/rpm/brp-compress ] && %{_libdir}/rpm/brp-compress
> There are several packages like this, and similar perl modules with 
> /usr/lib instead of %{_libdir}.  This fails to build on x86_64 for 
> obvious reasons.  While this isn't a problem for FC's build system 
> (everything is built on 32bit), we should fix these packages.
> 
> [ -x /usr/lib/rpm/brp-compress ] && /usr/lib/rpm/brp-compress
> While doing this would work,

Yeah, but it ignores the system's other rpmbuild configuration, eg.
redhat-rpm-config, which uses /usr/lib/rpm/redhat/brp-compress.  Not
that there would be too big differences between them nowadays, but to
illustrate.

> this may confuse people because our 
> packaging docs say to macroize everything.  Are there other cases where 
> macroizing directories is NOT the right thing to do?

All cases where it doesn't make sense?  I don't think it's possible to
give an exhaustive answer to that.  Packagers just have to know when to
use macros, and what macros, and when not to.  If packaging docs say
macroize everything, then I think the docs should be improved.

BTW, if one wants to keep the above explicit brp-compress's in, it'd be
better to change them to %{_prefix}/lib/rpm/..., see rpm.spec.

> And... any idea why these packages are running brp-compress anyway? 
> Doesn't this happen automatically without it?

It does, and I think those should be just removed from all specfiles.
They're probably initially from cpanflute2 which creates a lot of cruft
no longer needed in non-ancient RH(EL)/FC distro versions.