CROSS-LIST Notice: Changes In EPEL

Home » CentOS » CROSS-LIST Notice: Changes In EPEL
CentOS 14 Comments

If you use the EPEL repository, please read https://lists.fedoraproject.org/pipermail/epel-announce/2014-November/000032.html

TL;DR: There are a large number of orphaned/unmaintained packages in EPEL across the 5, 6, and 7 trees. These packages will be removed from EPEL unless they are picked up by a packager. Packages that *depend* on an orphaned package will be removed as well to ensure repo-closure.

Please review the package lists to see if something you use is impacted. If you’re impacted and you have the required skills, please consider taking over ownership of the package.

14 thoughts on - CROSS-LIST Notice: Changes In EPEL

  • Is there a command in yum where you can sort packages by repository and hence compare them with the lists you’ve provided?

    Brian Bernard

  • Hi Brien,

    We use rpm.

    listing all packages not in base repo,

    rpm -qa –qf ‘%{NAME} %{VENDOR}\n’ |grep -v CentOS

    or just Fedora packages(epel).

    rpm -qa –qf ‘%{NAME} %{VENDOR}\n’ |grep Fedora

    Thanks,

    Hcan.

  • Hi,

    Tuesday, November 4, 2014, 1:43:50 PM, you wrote:

    sorry for being so ignorant. I try to figure out what impact that has on a running system. I expect that this package cannot be updated from now on, but I hope that nothing catastrophic for an existing installation happens.

    Is that assumption correct?

    best regards

  • Hi Michael,

    Yes, in almost all situations running systems will never be affected by a package being dropped from a repository.

    If a system already has the package installed, and said package is already working then the package being removed from the repository should have no affect on your system what-so-ever.

    However the following will be broken:

    1) Automated kickstart installations which connect to EPEL to grab the package as it won’t be able to find the package to install it.

    2) The ability to install the package on a new/reinstalled system (yum install package)

    3) The ability to reinstall the package (yum reinstall package)

    4) The ability to get updated versions of the package (yum update package)

    Aside from the above, it should not brake anything else.

    The only time I think it would become an issue is if you updated from say EL8.0 to EL8.1 and the existing package stopped being compatible for some reason or other. This would mean the package would not receive an update to fix the compatibility unless someone grabbed the orphaned package and started to maintain it again, or you fixed it yourself.

    I’d recommend grabbing any orphaned package RPMs and SRPMs so you can still use them later if needed.

    Either that or volunteer to maintain the package you need :-).

    Hope this clears things up for you :-).

    Kind Regards, Jake Shipton (JakeMS)
    GPG Key: 0xE3C31D8F
    GPG Fingerprint: 7515 CC63 19BD 06F9 400A DE8A 1D0B A5CF E3C3 1D8F

  • As far as package installation goes, Jake outlined most things quite well. What’s being ignored is that this depends on the package. These packages aren’t maintained, so no one is checking them to see if there are security issues associated with them. If what you have installed is a service or application that is exposed to the outside world, then you have the possibility for exploit in the older, unmaintained version.

  • Does that mean the source coding will be “lost” forever ? and if someone in the future wants that functionality, they will have to re-invent the
    ‘wheel’ ?

  • Only the packaging templates and any patches. This is tracking people abandoning maintaining *packages*, not the upstream source.

    I suspect that the packaging templates will continue to remain in the git history, even if the most recent commits will be to mark them as abandoned.

  • If you are running multi-user machine you better assume that bad guys may be already inside. (Say, stolen password for some account). This means:
    you shouldn’t have any local exploits as well (the ones allowing privilege elevation). And you should have things set up so that local DOS is impossible (e.g. no regular user can run the spool out of file handlers).

    It depends on why package is not available anymore. There can be at least one of two reasons:

    1. Code developer(s) stopped working/maintaining code for one reason or another. Well written code may still be usable for some half a year or so. Then one will need to find another software with similar functionality

    2. Code developing team is still actively working on it, but packaging for some distribution is done by different people who stopped doing it. Then one can uninstall package, and install it from source. No need to stress that one has to subscribe for announcements code team sends (to make sure one doesn’t miss important updates).

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Also note, the announcement is not very clear on which EL version is being orphaned. For example, python-boto is being orphaned, but it appears that this is only for EL5.

    K

  • The announcement includes links to each version, 5,6 and 7. The package lists are different for each. Being removed in 5 doesn’t automatically mean it’s gone from 6 or 7. People will need to check the lists for each version they run.