Hi Owen,

On 20/08/15 18:01, Lamar Owen wrote:
> It's easy to miss since it previously wasn't a hard requirement for
> rpm-build, but it's been there since the beginnings of SL6.

Ah, OK.

So, redhat-rpm-config was present and manually installing it would 
result in the system building RPMs that are, by default, not compatible 
with SL-5.

>> I can carry on with the work-around I found.
>
> I actually appreciate your posting of the workaround, since for
> package-building for EL5 I have kept an EL5 buildhost for some internal
> packages, since I hit this with EL6.0 back in 2011.  But I have
> installed redhat-rpm-config as part of my standard package-building
> installation in EL6 since I first started using EL6 (I use CentOS 6 for
> the most part, but CentOS and SL are almost identical for my purposes).

We (at dCache.org) are pretty lucky since we use Java and a small number 
of POSIX shell scripts (we try to avoid bash-isms).

The result is that a binary tar-ball should work on almost any machine 
with a POSIX shell and a JVM (including a Raspberry Pi), which makes it 
easier to build an RPM that should work on any platform.

>> The problem is that earlier versions of dCache don't have explicitly
>> configured hash and compression values in their spec files.  This
>> means that I now cannot rebuild earlier tagged dCache versions and get
>> the same RPMs.
>
> I understand your frustrations.
>
>>
>> Do you know where and how I should report this?
>
> You could probably report it to Red Hat's bugzilla, but it would likely
> be closed WONTFIX.

OK, I'll take the hint :)

At least anyone who suffers from the same problem can create the 
appropriate file as a work-around.

Here's the file I added to our build machines:

[root@sisyphus ~]# cat /etc/rpm/macros.sl5-compat
%_source_payload  w9.gzdio
%_binary_payload  w9.gzdio
%_source_filedigest_algorithm 1
%_binary_filedigest_algorithm 1
[root@sisyphus ~]#

HTH,

Paul.