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.
RFC: Removing eclasses
