1 |
Ryan Hill wrote: |
2 |
> Alec Warner wrote: |
3 |
> |
4 |
>> Another class of packages I wish to discuss (not remove quite yet, just |
5 |
>> talking ;) ) are older packages with stable markings. By Stable I mean |
6 |
>> debian stable, IE we stabled it in 2004 and no one has touched it since. |
7 |
>> |
8 |
>> Do these packages still work with a current system (linux 2.4/2.6, |
9 |
>> glibc-2.3/2.4, >=gcc-3.4, etc... |
10 |
>> |
11 |
>> So partially this is a question for gcc porting, how many *known broken* |
12 |
>> apps don't get fixed when we upgrade and stable a gcc version. |
13 |
> |
14 |
> Depends how much notice we get ahead of time. Things like 'btw we want |
15 |
> 4.1 stable for 2006.1' two weeks in advance tend to create more havoc |
16 |
> than usual. |
17 |
> |
18 |
>> Do these stay in the tree, and do they have deps on older versions of |
19 |
>> gcc (effectively masking them, since old versions of gcc generally get |
20 |
>> masked by |
21 |
>> profile eventually). |
22 |
> |
23 |
> Most major archs have at least some version of 3.3 and 3.4 available in |
24 |
> stable. Sometimes even 2.95, and some lucky winners have 4.1 in ~arch. |
25 |
> amd64 has 3.3 masked for some reason i don't understand, and other |
26 |
> arches might too. i'm just going off of what eshowkw tells me. |
27 |
> |
28 |
> Unless there's a very good reason, older GCC versions shouldn't be |
29 |
> punted because it's extremely useful to be able to test your code on a |
30 |
> variety of different compilers. |
31 |
> |
32 |
|
33 |
I'm not sure if I'm misreading here, I'm not advocating we dump older |
34 |
gcc versions. Moreso I'm advocating we dump code that doesn't compile |
35 |
with newer gcc/toolchain versions that no one is willing to fix. We |
36 |
have had devs in the past bring in far too many packages and then just |
37 |
leave, so half of them get picked up by other devs, and the other half |
38 |
sit there and rot. Mostly once again, maintainer-needed packages :0 |
39 |
|
40 |
>> How many apps are just sitting in the tree and no one knows if they |
41 |
>> compile at all with a recent system? |
42 |
> |
43 |
> Once I'm through with them, hopefully none. ;) I know of a couple |
44 |
> packages that won't compile with GCC 3.3, but for most I have a patch or |
45 |
> workaround. libmpeg3 is one, can't remember any others off the top of |
46 |
> my head. |
47 |
> |
48 |
>> I think also that genone's Gentoo-Stats project would be a great |
49 |
>> information aggregator as we could identify packages that no one uses |
50 |
>> anymore. |
51 |
> |
52 |
> +1 |
53 |
> |
54 |
>> Anyway, these were just some thoughts I had about trimming the tree a |
55 |
>> bit; feel free to rip em apart as always :0 |
56 |
> |
57 |
> BTW, I'm interested in joining the Tree Cleaners project once my dev |
58 |
> stuff goes through, if it's cool with you. |
59 |
> |
60 |
|
61 |
cool |
62 |
|
63 |
> --de. |
64 |
> |
65 |
|
66 |
-- |
67 |
gentoo-dev@g.o mailing list |