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.