[gentoo-dev] Re: Stable Staleness (mostly toolchain)
Ryan Hill [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 30 Jul 2006 16:56:47 -0600: Most major archs have at least some version of 3.3 and 3.4 available in stable. Sometimes even 2.95, and some lucky winners have 4.1 in ~arch. amd64 has 3.3 masked for some reason i don't understand, and other arches might too. i'm just going off of what eshowkw tells me. FWIW on amd64 and gcc (as a Gentoo/amd64 user not necessarily privy to certain Gentoo/amd64 dev team details) ... gcc-3.3 is masked on amd64 due to multilib issues. Gentoo/amd64 multilib handling has matured and changed over time, with the new handling being introduced and stabilized along with a new profile and gcc-3.4. gcc-3.3 wasn't upgraded to the new multilib handing, in part because its amd64 support wasn't all that great anyway -- it worked, but was bolted on and it showed -- so with 3.4's amd64 handling being better already, and limited resources available, 3.3 was masked on what was then the new profiles, and support deprecated and eventually phased out in parallel with the older profiles and their older multilib handling. Actually, talking gcc4 now, on amd64, I'd compare the jump from 3.4 to 4.1 to a full version jump if not more, 3.1 to 4.1 if not 2.9x to 4.1, on x86. Thus it wouldn't surprise me to see 3.4 go the way of 3.3, some time in 2007. It can remain keyworded but masked for those who want to play with the older versions beyond that, but without any sort of support for those choosing to do so. Again, I'm not a devel and my opinions do not the future path of Gentoo/amd64 denote, but there's a big enough difference in performance, IMO, that beyond a reasonable gcc4 stabilization and gcc3 deprecation period, it makes little sense to continue to support gcc3. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Stable Staleness (mostly toolchain)
Alec Warner wrote: Another class of packages I wish to discuss (not remove quite yet, just talking ;) ) are older packages with stable markings. By Stable I mean debian stable, IE we stabled it in 2004 and no one has touched it since. Do these packages still work with a current system (linux 2.4/2.6, glibc-2.3/2.4, =gcc-3.4, etc... So partially this is a question for gcc porting, how many *known broken* apps don't get fixed when we upgrade and stable a gcc version. Depends how much notice we get ahead of time. Things like 'btw we want 4.1 stable for 2006.1' two weeks in advance tend to create more havoc than usual. Do these stay in the tree, and do they have deps on older versions of gcc (effectively masking them, since old versions of gcc generally get masked by profile eventually). Most major archs have at least some version of 3.3 and 3.4 available in stable. Sometimes even 2.95, and some lucky winners have 4.1 in ~arch. amd64 has 3.3 masked for some reason i don't understand, and other arches might too. i'm just going off of what eshowkw tells me. Unless there's a very good reason, older GCC versions shouldn't be punted because it's extremely useful to be able to test your code on a variety of different compilers. How many apps are just sitting in the tree and no one knows if they compile at all with a recent system? Once I'm through with them, hopefully none. ;) I know of a couple packages that won't compile with GCC 3.3, but for most I have a patch or workaround. libmpeg3 is one, can't remember any others off the top of my head. I think also that genone's Gentoo-Stats project would be a great information aggregator as we could identify packages that no one uses anymore. +1 Anyway, these were just some thoughts I had about trimming the tree a bit; feel free to rip em apart as always :0 BTW, I'm interested in joining the Tree Cleaners project once my dev stuff goes through, if it's cool with you. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Stable Staleness (mostly toolchain)
Ryan Hill wrote: Alec Warner wrote: Another class of packages I wish to discuss (not remove quite yet, just talking ;) ) are older packages with stable markings. By Stable I mean debian stable, IE we stabled it in 2004 and no one has touched it since. Do these packages still work with a current system (linux 2.4/2.6, glibc-2.3/2.4, =gcc-3.4, etc... So partially this is a question for gcc porting, how many *known broken* apps don't get fixed when we upgrade and stable a gcc version. Depends how much notice we get ahead of time. Things like 'btw we want 4.1 stable for 2006.1' two weeks in advance tend to create more havoc than usual. Do these stay in the tree, and do they have deps on older versions of gcc (effectively masking them, since old versions of gcc generally get masked by profile eventually). Most major archs have at least some version of 3.3 and 3.4 available in stable. Sometimes even 2.95, and some lucky winners have 4.1 in ~arch. amd64 has 3.3 masked for some reason i don't understand, and other arches might too. i'm just going off of what eshowkw tells me. Unless there's a very good reason, older GCC versions shouldn't be punted because it's extremely useful to be able to test your code on a variety of different compilers. I'm not sure if I'm misreading here, I'm not advocating we dump older gcc versions. Moreso I'm advocating we dump code that doesn't compile with newer gcc/toolchain versions that no one is willing to fix. We have had devs in the past bring in far too many packages and then just leave, so half of them get picked up by other devs, and the other half sit there and rot. Mostly once again, maintainer-needed packages :0 How many apps are just sitting in the tree and no one knows if they compile at all with a recent system? Once I'm through with them, hopefully none. ;) I know of a couple packages that won't compile with GCC 3.3, but for most I have a patch or workaround. libmpeg3 is one, can't remember any others off the top of my head. I think also that genone's Gentoo-Stats project would be a great information aggregator as we could identify packages that no one uses anymore. +1 Anyway, these were just some thoughts I had about trimming the tree a bit; feel free to rip em apart as always :0 BTW, I'm interested in joining the Tree Cleaners project once my dev stuff goes through, if it's cool with you. cool --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Stable Staleness (mostly toolchain)
Alec Warner wrote: I'm not sure if I'm misreading here, I'm not advocating we dump older gcc versions. Moreso I'm advocating we dump code that doesn't compile with newer gcc/toolchain versions that no one is willing to fix. We have had devs in the past bring in far too many packages and then just leave, so half of them get picked up by other devs, and the other half sit there and rot. Mostly once again, maintainer-needed packages :0 Sorry, for some reason I reversed the entire meaning of your message to refer to packages that build with the current toolchain but not an older one. I blame the hangover and the strangely persuasive goat people. Right now I'm in the middle (well, okay, maybe first quarter) of getting everything in stable working with GCC-4.1.1. If (when) I encounter anything that makes me run away arms flailing in horror I will be happy to CC tree-cleaners (misery loves company) ;). --de. -- gentoo-dev@gentoo.org mailing list
