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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
