EPEL [Extra Packages for Enterprise Linux] #7: Policy and technical means for removing orphaned packages in
#7: Policy and technical means for removing orphaned packages in EPEL ----------------------------+---------------------------- Reporter: smooge | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: Component: Policy problem | Version: Keywords: | ----------------------------+---------------------------- 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.
#7: Policy and technical means for removing orphaned packages in EPEL -----------------------------+---------------------------- Reporter: smooge | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: Component: Policy problem | Version: Resolution: | Keywords: -----------------------------+----------------------------
Comment (by till):
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.
#7: Policy and technical means for removing orphaned packages in EPEL -----------------------------+---------------------------- Reporter: smooge | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: Component: Policy problem | Version: Resolution: | Keywords: -----------------------------+----------------------------
Comment (by smooge):
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?
#7: Policy and technical means for removing orphaned packages in EPEL -----------------------------+---------------------------- Reporter: smooge | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: Component: Policy problem | Version: Resolution: | Keywords: -----------------------------+----------------------------
Comment (by till):
Replying to [comment:2 smooge]:
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?
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.
#7: Policy and technical means for removing orphaned packages in EPEL -----------------------------+---------------------------- Reporter: smooge | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: Component: Policy problem | Version: Resolution: | Keywords: -----------------------------+----------------------------
Comment (by jperrin):
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.
#7: Policy and technical means for removing orphaned packages in EPEL -----------------------------+---------------------------- Reporter: smooge | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: Component: Policy problem | Version: Resolution: | Keywords: -----------------------------+----------------------------
Comment (by smooge):
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.
#7: Policy and technical means for removing orphaned packages in EPEL -----------------------------+---------------------------- Reporter: smooge | Owner: epel-wranglers Type: task | Status: new Priority: major | Milestone: Component: Policy problem | Version: Resolution: | Keywords: -----------------------------+----------------------------
Comment (by till):
Replying to [comment:5 smooge]:
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.
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.
epel-devel@lists.fedoraproject.org
-
EPEL