On 10/28/2017 11:33 AM, H wrote: > On October 27, 2017 5:54:45 PM EDT, Frank Cox <theatre@xxxxxxxxxxx> wrote: >> On Fri, 27 Oct 2017 17:32:03 -0400 >> H wrote: >> >>> How do I best encourage maintainers to update the software they are >>> responsible for in various repositories? >> >> If it's something that you need or want and it's not available in a >> repo that you currently use you can compile it yourself. >> >> I do that with a number of packages that are either newer or simply not >> available in the various Centos repos. In many cases it's as easy as >> downloading a new tar source file and adding it to the existing source >> rpm, doing three seconds of editing on the spec file to account for the >> new update, and compiling the result. Sometimes it's even easier -- >> just download a newer Fedora rpm and compile that on your Centos >> system. In a lot of instances, the upstream program's project that maintains it prohibits upgrades / updates by the requirements for their software. Sometimes it will require a newer gcc to compile, or a newer php to run, or newer gtk+ or newer something else. This would require many changes to build on older versions of shared libraries in Enterprise Linux distros. This is a choice by the project that controls that software. Backporting (https://access.redhat.com/security/updates/backporting) is very difficult, and is a main reason that RHEL needs to be a paid for service. People want stable, long lived software that is secure for the enterprise. That is the whole purpose of this type of distribution. You can't really expect repo maintainers to have the skills or time to backport newer software to an Enterprise distro. If the project that maintains that software wants it to work in the enterprise, they should maintain long term support for their software.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx https://lists.centos.org/mailman/listinfo/centos
