[CentOS] How to encourage maintainers to update their software

Tue Nov 7 14:10:34 UTC 2017
Lamar Owen <lowen at pari.edu>

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.