| 1 |
As the lead for the treecleaner project (team, whatever you want to call |
| 2 |
it wolf ;) ), I've been trying to fix old broken packages, many have |
| 3 |
been slated for removal, some have had minor fixes, and others are still |
| 4 |
setting waiting for me to get some free time. |
| 5 |
|
| 6 |
Another class of packages I wish to discuss (not remove quite yet, just |
| 7 |
talking ;) ) are older packages with stable markings. By Stable I mean |
| 8 |
debian stable, IE we stabled it in 2004 and no one has touched it since. |
| 9 |
|
| 10 |
Do these packages still work with a current system (linux 2.4/2.6, |
| 11 |
glibc-2.3/2.4, >=gcc-3.4, etc... |
| 12 |
|
| 13 |
So partially this is a question for gcc porting, how many *known broken* |
| 14 |
apps don't get fixed when we upgrade and stable a gcc version. Do these |
| 15 |
stay in the tree, and do they have deps on older versions of gcc |
| 16 |
(effectively masking them, since old versions of gcc generally get |
| 17 |
masked by profile eventually). |
| 18 |
|
| 19 |
How many apps are just sitting in the tree and no one knows if they |
| 20 |
compile at all with a recent system? |
| 21 |
|
| 22 |
Solar already has some decent tinderboxing scripts, it would be |
| 23 |
interesting to me to have a system to keep track of the known state of |
| 24 |
certain categories of packages that are...less used ;) |
| 25 |
|
| 26 |
I think also that genone's Gentoo-Stats project would be a great |
| 27 |
information aggregator as we could identify packages that no one uses |
| 28 |
anymore. |
| 29 |
|
| 30 |
Anyway, these were just some thoughts I had about trimming the tree a |
| 31 |
bit; feel free to rip em apart as always :0 |
| 32 |
|
| 33 |
-Antarus |
| 34 |
-- |
| 35 |
gentoo-dev@g.o mailing list |
Archives