On 10/28/2017 01:28 PM, Japheth Cleaver wrote: > It didn't seem to use to be that case. IMO it makes a lot more sense > to wrap distro-specific .spec file changes in conditionals and let the > rpmbuild do the right thing than to post and maintain separate > versions for Fedora, EPEL, and anything else. In my former role as package maintainer for the PostgreSQL development group several years ago, I was contracted to do RPMs for several different distributions. And while this was several years ago, the basic RPM mechansims have not changed that significantly, and this kind of maintenance can become a rat's nest nightmare very quickly. I found that, specifically for PostgreSQL, the complexity increase was not linearly proportional to the number of distributions and versions of distributions supported; rather, it was much more like a cubic or quartic relationship with multiple poles and zeroes (using Z transform terminology) and pitfalls everywhere. The current PostgreSQL RPm maintainers do a great job supporting what they do, but it is not easy at all to support more than four distribution versions with one spec file. Now, this thread is also talking about doing your own rebuilds, and, to a point, this works quite well. Especially in cases where the EPEL maintainer simply refuses to update a package because it would cause a version bump of that particular package and 'version bumps require Deep Reasons' (paraphrased from an actual response). My experience maintaining the PostgreSQL RPMs prepared me well for some of the things I have rebuilt (such as kicad) on C7. HOWEVER, there is a hard and fast and totally inviolate rule to rolling your own rebuilds: "You break it, you keep it." You are taking your own system's stability into your own hands; for some packages (like kicad, or gnuradio, or other relatively stand-alone packages that don't require major shared library replumbing) it's fairly easy and safe to do your own builds; for some packages it is going to be nearly impossible if the packages' upstream developers haven't made it easy to locally build their dependencies with the sometimes very specific version requirements (case in point: Ardour). And some of these packages have no security footprint as far as updates are concerned (web browsers and email clients absolutely have major security footprints and need to stay updated, but something like kicad does not). There are automated tools to do these sorts of things, such as the perl script 'smock' which does a reasonable job doing source build dependencies, as long as the buildrequires deps in the source RPM are proper and there are no hidden ones (experienced RPM rebuilders know I say that a bit tongue in cheek). Whatever you do, do NOT rebuild as root. Mock and similar tools make it possible to have reproducible builds, and it is strongly encouraged that these tools be used. BUT, again, "you break it, you keep it" applies strongly because that package you built might have required a package that isn't currently in C7 but might be added at some future date, and your hand-built package might cause a real security update to fail in weird ways. Caveat aedificator, perhaps? You are then responsible to keep your hand-built dependency updated yourself.