On Tue, 7 Nov 2017, Mátyás Selmeci wrote: > This highlights a problem I've occasionally had with EPEL, namely that > packages I depend on occasionally get removed. This especially causes trouble > when a package gets removed because it's now in RHEL, because it takes a few > months for CentOS and Scientific Linux to update. Perhaps you could create an > 'epel-unsupported' repo and move packages there instead of removing them?
As others have suggested, running a private mirror of (at least) the SRPMs and learning how to build them, or a larger mirror including binaries, and optionally locally '[re-]signing' them as Smooge mentioned {nice trick, btw, smooge} comes to mind. I don't have to fiddle with the underlying scripts except to add new point releases (of CentOS), and less frequently, of EPEL People have tried over the years to put together busineses (Progeny, me) or community projects (Fedora Legacy), but economically finding the paying customer mass (and it may well not exist) is not there to justify doing that as a 'full time' occupation, so it rather becomes an adjunct to consulting when custom building, ports, and back-ports for i in lftp-epel-6.conf lftp-epel-7.conf lftp-epel-testing-6.conf lftp-epel-testing-7.conf ; do NONCE=` grep -v ^# $i | tail -n 1 ` ; du -sh ${NONCE} ; find ${NONCE} -type f | wc -l ; echo "" ; done 11G /share/MD0_DATA/Mirror/redhat/epel/6 5966 17G /share/MD0_DATA/Mirror/redhat/epel/7 6534 709M /share/MD0_DATA/Mirror/redhat/epel/testing/6 391 2.3G /share/MD0_DATA/Mirror/redhat/epel/testing/7 953 ... I have a bit north of 750k SRPMS in my local archive and a suite of tools to handle that porting and back-porting developed over ... almost 20 years ... goodness -- Russ herrold _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org