Hi, Currently the approach is that you must mark the eclass as deprecated and wait 2 years in order to remove it.
I would propose to do it more fine grained. Since portage 2.1.4.0 the environment is stored and preserved, thus eclasses are no longer required for package uninstalls (which is the only reason for above rule). Bit research for history here when 2.1.4.0 or later was stabilised reveals the date Mon Feb 18 09:51:22 2008 UTC. [1] As we can say everyone even stable people potentialy update to before 1st August during individual updates. We can safely assume that after 4 months noone use individual commands and gets it grabbed using @world or @system target. So we can set the date on: 2008-08-01 So we can have 2 case scenario here now. Eclass is newer than this date It can be removed right away since portage is using the environment, thus the eclass would be just wasting space and looking ugly :P Eclass is older than the date Here we need to find out if it is used, and if it is used it needs to go full 2 years period before removal. If it is no-longer used, the 2 years period started ticking when the last ebuild using such eclass was in main tree. Cheers [1] - http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys- apps/portage/portage-2.1.4.4.ebuild?hideattic=0&rev=1.10&view=log -------- Tomáš Chvátal Gentoo Linux Developer [KDE/Overlays/QA/Sunrise/X11] E-Mail : [email protected] GnuPG FP : 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587 GnuPG ID : 03414587
signature.asc
Description: This is a digitally signed message part.
