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