How To Encourage Maintainers To Update Their Software

Home » CentOS » How To Encourage Maintainers To Update Their Software
CentOS 19 Comments

How do I best encourage maintainers to update the software they are responsible for in various repositories?

Akema Yagi made sure kmod-jfs for CentOS 7 was updated amazingly fast which is greatly appreciated. On the other hand, I have requested updates of some other software packages and have heard absolutely nothing in months…

19 thoughts on - How To Encourage Maintainers To Update Their Software

  • 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 ( 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.

  • It would be nice if this remained even a *suggestion* at the Fedora layer, but there seems to be from occasional obliviousness to outright hostility to the idea of keeping spec files broadly compatible across a range of downstream releases and for other RPM-based distributions, or not ripping out compatibility at Fedora-speed. (Even leaving aside
    “burn-the-ships” actions like outright banning SysV init scripts.)

    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.


  • If people want all the newer packages that exist in Fedora .. why not just use Fedora?

    Enterprise distributions are designed to be maintained for 10 years so when you make an investment of X million dollars in a piece of software, you can use it for an extended period of time. Having all the latest packages is not what Enterprise Linux is about. That is what Fedora is about.

    Fedora has introduced a new feature called modularity
    ( Eventually, when / if modularity is rolled into Red Hat Enterprise Linux, you will get some more flexibility in RHEL (and therefore CentOS as we use RHEL sources).

    CentOS Linux is a great Linux distribution. We want everyone to use it. But trying to convert CentOS Linux into Fedora is not only redundant
    (Fedora already exists .. use it) .. a bastardized version of CentOS
    with hundreds of newer manually maintained components is not really CentOS, and Fedora is likely more stable than that monstrosity anyway.

    There are things to add newer pieces to CentOS (SCL SIG, PaaS SIG, etc.), and those can be done now and integrated into the Enterprise Distro. If those are what you need, that is what they’re for.

  • There’s a difference between upgrading core operating system functionality and a changing a few userland programs. I compile the latest versions of Sylpheed and astyle (for example) and use those programs on my CentOS 7 desktop computer. I don’t see any issue with doing things like this and don’t believe that it decreases the stability of the system.

    I don’t want to tear my whole computer down and upgrade my operating system every six months, and I don’t want to deal with the bleeding-edge stuff that might or might not work when it affects something like network connectivity or whether I actually get a picture on the screen when I boot up my computer. But for userland programs, why not run the latest version of Libreoffice or Cool Reader if it’s easy to compile them and I can get a few new features out of it?

  • Well, I am trying to get a couple of applications compiled that I believe are quite compatible with the positioning of CentOS:

    – The graphical configuration utility for fcitx (fcitx-configtool) is missing and any configuration presently has to be done by manually editing the complex configuration files which are very poorly documented. Thus configuration of fcitx for e.g. entering/editing Chinese text took a long time and I still have a couple of issues that I have been unable to resolve.

    – The geany editor is missing the markdown plugin, this however, may shortly be resolved.

    – I’d love to have keepassx updated so bugs are fixed and the file format becomes compatible with the file format used by its Windows counterpart and files thus interchanged without any problems.

    – pdfshuffler is not available for CentOS 7, only CentOS 6.

  • I don’t know anything about Chinese text rendering.

    Check on my website. :)

    The rest of your stuff is easily dealt with by compiling the relevant Fedora rpms.

    Download this:

    and you can have this:


    I just tried it and it took only a few minutes.

    I just compiled this

    It took about three seconds to do the whole job and now I have this:


    You can easily do the same if you wish. Just install rpmdevtools and any necessary dependencies for the rpm that you want to compile and off you go. The rpmbuild command will even tell you about any missing dependencies. For example, my first attempt at compiling keepassx told me:

    error: Failed build dependencies:
    libXtst-devel is needed by keepassx-1:2.0.3-1.el7.CentOS.x86_64
    libgcrypt-devel is needed by keepassx-1:2.0.3-1.el7.CentOS.x86_64

    To fix it I did this:

    yum install libXtst-devel libgcrypt-devel

    My next attempt to compile the keepassx rpm worked.

    This isn’t a guaranteed solution for absolutely every rpm or program that you might ever come across; sometimes you get into a dependency rabbit hole that never seems to end and it becomes more work than it’s worth to solve. Other times you get stuff that requires a newer or different version of something that’s way too much work to upgrade or change. But in a lot of cases, you can just download and compile your own rpm as needed. As you see here, two items on your wish list are easily handled this way in less than five minutes. It took me longer to write this email than it did to download and compile those programs.

  • And as long as that works and they compile against the base shared libraries, that is fine.

    But that is usually NOT the case and newer versions of LibreOffice or the others usually need a newer gtk or newer something else, etc.

    I am all for adding content that does not exist .. if there is a long term upstream for it. I am, for example, adding a 4.9.x LTS kernel for newer x86_64 or i386 embedded type boards that can also be used on newer hardware if required
    ( , see Experimental Repository)

    But, it took me longer (and more effort) to make that one package work with CentOS Linux 7 than it took for me to create the first 7.0.1406 tree.

  • The problem with compiling the relevant fedora SRPMs is .. once fedora moves to a version (in their tree) that no longer compiles on CentOS
    because of shared library issues, any security updates dry up. If you have not found an upstream (of Fedora) source for updates for that version of the software in question, you either have to learn how to backport (, live with software that contains security issues, or compile a newer version of Fedora’s software. Many times, that means adding in a newer version of dependent shared libraries. And that can mean having to recompile other things that depended on the shared libraries that you upgraded (or building statically, etc.).

    I recently had to go through that with the 3.18.x kernel that we used in the Xen4CentOS repo in the Virt SIG. I worked on another LTS kernel
    (4.9.x) for about a month before 3.18.x went EOL from .. then it took us about another 2 months of testing in the Virt SIG to get a fairly stable kernel build that worked for the xen Dom0 kernel.

    The reason that every package in Fedora which is removed from RHEL is not in EPEL is that it is very hard to properly backport items and find new streams of updates that can keep older ABI/API compatibility and main software secure after the project that maintains it moves on. It is also a major reason Red Hat employs thousands of engineers to do it and why people pay them billions of dollars a year to maintain it.

    So yes, it can be done .. but if you are trying to do it for 10 or so years, it is not easy.

  • Well, I am not Frank, but you download the SRPM (I use wget) and put it into a directory.

    Then you extract it .. there are many ways to do that .. I do this:

    rpm -Uvh –define “_topdir $(pwd)” –nodeps

    Then you have an exploded SRPM with a SPECS/ and SOURCES/ directory. You then need to edit the SPECS/.spec file and verify each line in the spec file will work with EL7 instead of fc25 (or whatever version of Fedora you got the SRPM from). This includes but is not limited to knowing the differences in the rpm macros between that version of Fedora’s rpmbuild and CentOS 7’s rpmbuild .. what the versions of shared libraries (or other dependencies like python, etc.) are for that version of Fedora and CentOS 7 .. which one of those shared dependencies are required or can be degraded in version to the ones in CentOS 7.

    Basically, the SRPMs from Fedora 18 generally had all the required dependencies for RHEL / CentOS for the 7.0 release cycle source code .. BUT with rebases in every point release since the 7.0 cycle,, that is no longer true. Now some components (like Gnome) have very newer dependencies while others still have the dependencies from Fedora 18.

    Fedora 18 stopped getting updates and went EOL on 2014-01-14 .. any packages that you build based on those SRPMs need to get a new source code stream so that you can continue to get security fixes .. or you have to take the newer source code and backport the changes to the Fedora 18 based SRPMS .. or you have to get newer versions of the package and build it against the current CentOS 7 provided shared dependencies, upgrading any dependencies that are too old. THEN you have to rebuild any other packages in CentOS that used the older dependencies from CentOS 7 that you just upgraded. THEN you need to maintain not only the package that you wanted to build the way that you just did .. now you also need to maintain all those dependencies that way .. AND .. you need to maintain all of the new CentOS packages that you had to rebuild based on those dependencies in the same way. That could mean that to add one thing, you now need to maintain 20 packages.

    And if you are taking things from Fedora 25 (as an example) to CentOS 7, you need to be concerned about things like .. a different location for kernel install tools .. a different major version of python (python2 vs python3) .. a majorly different version of GNOME and KDE, differences in samba, in NFS, etc. etc.

    Again, that is why Red Hat has thousands of engineers to maintain the Enterprise Linux sources.

  • This is one of the reasons I’m in favor of bringing Flatpak to Fedora
    (and presumably also eventually to CentOS). We have a project to automatically convert Fedora packages to Flatpaks, which you could then run on a CentOS base.

    That’s really just an approach for desktop apps, though. Fedora Modularity aims to solve this for other software stacks, allowing you to keep longer-lived streams for the stuff you don’t want to change, and faster streams for the stuff you do want different.

    All that said, I do also feel *some* need to mention that Fedora gives you a 13-month lifecycle, not six months. And, in most cases, you can upgrade in under half an hour without no fuss.

  • The complexity of doing this will vary a lot with what you’re trying to compile, but for userland programs like email clients, text editors, games and the like it can be very easy to do in a lot of cases.

    As Johnny says, you don’t really want to do this with core operating system functions since you can end up with a Frankenstein system that might not work properly any more.

    In many cases (more than a few but by no means all) you can compile a Fedora rpm for CentOS using the following procedure.

    You need to have rpmdevtools installed:

    yum install rpmdevtools

    Now set up the build directory structure in your home directory:


    After that, download the Fedora srpm, then run a rpmbuild command against the rpm you downloaded:

    rpmbuild -ba nameofsourcerpm.src.rpm

    Now you see what happens. Sometimes the process will run and you’ll end up with a rpm file in ~/rpmbuild/RPMS/. If so, then you’re done. You’ve got the CentOS rpm that you wanted.

    If the process errors out then your next step depends on the nature of the error. If it’s a missing dependency then you might be able to simply install that dependency:

    yum install nameofdependency

    Then run the rpmbuild command again and see if it works.

    If you can’t find a pre-built rpm of the missing dependency then you might be able to build it yourself using the above process. Or not. It depends on the circumstances and what’s missing. If the program requires a newer version of a dependency that you already have installed, you might want to re-consier your plan at that point. See above about creating a Frankenstein system.

    If the process errors out due to something other than a missing dependency, things become a bit more complex at that point. If you look in ~/rpmbuild/SPECS you will find a .spec file for your rpm. Crank up your text editor and inspect that and see what it’s doing and where things go wrong. Sometimes it’s useful to simply compile the original source file directly and see if that works. (You can find that in ~/rpmbuild/SOURCES. )

    If the original source file compiles but the rpm doesn’t, then there’s likely a fix that you need to do to the spec file to make it work. Sometimes it’s useful to compare the spec file for an older version that does work on CentOS with the spec file for a newer version that doesn’t, and see what changed.

    If the source file doesn’t compile then you have bigger problems to solve — perhaps you need to patch the sources or perhaps it just plain won’t work on CentOS. That’s the place where I’ll usually give up unless it’s really important to me to get it to work.

    If it is really important (that doesn’t happen very often) then I keep a sacrificial CentOS 7 Virtual Box image that I can use to experiment with changing some of the stuff that’s under the hood without worrying about blowing up my main desktop. But again, that doesn’t happen very often.

    Note that some Fedora stuff won’t work on CentOS. Period.

    But some stuff will work just fine.

  • The complexity of doing this will vary a lot with what you’re trying to compile, but for userland programs like email clients, text editors, games and the like it can be very easy to do in a lot of cases.

    As Johnny says, you don’t really want to do this with core operating system functions since you can end up with a Frankenstein system that might not work properly any more.

    In many cases (more than a few but by no means all) you can compile a Fedora rpm for CentOS using the following procedure.



    Thanks very much for explaining this process. I would like to have orthanc usable for CentOS 7, but the epel repos only have it for CentOS

    I will give your outline a try!!!


  • 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.