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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
