Fedora ESCO has set a policy that packages that have been orphaned will be automatically removed after 6 weeks from channels. till has been working on a set of scripts to give proper notice of these orphaned packages and the chain of dependencies so that other packagers can be prepared for either taking up the package or their own package not working.
It was wondered if we should look at doing this in EPEL as we have had a sort of policy on doing this but not a formal one. It was decided at the 2014-10-03 meeting to set up the scripts for reporting problems and then seeing how big a hole we are in before doing any sort of auto-removal. Further discussion is to be in this ticket and future meetings.
Discussed here: http://meetbot.fedoraproject.org/epel/2014-10-31/epel.2014-10-31-20.01.html
On December 17, 2014, EpSCO will be cleaning out the EPEL repositories of all orphaned packages. Packages that are orphaned will be removed and all packages depending on those orphaned packages will be removed from the repository. Packagers requiring packages need to take over orphaned packages.
I can take care of retiring packages, but I am not sure whether I will be able to do it exactly on the specified day.
Till. Thanks for offering. I am expecting we will be setting up a practice orphan and removal in early December to try and script this. The main thing is going to be how far does the recursion go when we remove all these packages?
Replying to [comment:2 smooge]:
Since you announced that all packages with broken dependencies are to be removed, I suggest to first retire all removed orphans and then use the repoclosure output from the following days to retire the remaining packages with broken dependencies. This will also take into account if dependencies are provided by RHEL/CentOS and orphaned EPEL packages (e.g. if a package was orphaned but not retired when a package moved from EPEL to RHEL). My script only looks at the EPEL packages.
There could be discrepancies between CentOS and RHEL for provided packages. As an example, we have some golang packages in the CentOS-7 Extras repository that are not provided in RHEL, but are needed as build dependencies for docker. We've added these to ensure things are self-hosting. RHEL doesn't provide them since they're only required to build, not run the application.
This may complicate your repoclosure tests if you're checking against OS packages as well.
Jim. I would say that if the package is not shipped in RHEL but used just for 'building' stuff then it is something we can look at for shipping with EPEL.
Till, fair plan. I guess we need to break the date down into two Dec 17th remove Orphans. Dec 19th remove children. I will try and do a trial run later this month to get an idea of how much is going.
Replying to [comment:5 smooge]:
I am not sure whether repoclosure identifies broken deps recursively, therefore it might require more runs. Do you want to look into repoclosure in the trial run? Everything else is straight forward from my perspective.
Metadata Update from @smooge: - Issue assigned to smooge
I believe this was fixed in 2015
Metadata Update from @smooge: - Issue close_status updated to: Fixed
Login to comment on this ticket.