From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1GJuee-000471-I5 for garchives@archives.gentoo.org; Sun, 03 Sep 2006 16:17:05 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k83GFR27020180; Sun, 3 Sep 2006 16:15:27 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.13.8/8.13.6) with ESMTP id k83GBZJW029934 for ; Sun, 3 Sep 2006 16:11:36 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id A14276517C for ; Sun, 3 Sep 2006 14:01:00 +0000 (UTC) Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16822-12 for ; Sun, 3 Sep 2006 14:00:53 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 4793965109 for ; Sun, 3 Sep 2006 14:00:50 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GJsWb-0001Zr-Eq for gentoo-dev@gentoo.org; Sun, 03 Sep 2006 16:00:37 +0200 Received: from ip68-230-97-209.ph.ph.cox.net ([68.230.97.209]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Sep 2006 16:00:37 +0200 Received: from 1i5t5.duncan by ip68-230-97-209.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Sep 2006 16:00:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: "Duncan" <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Gentoo 2006.1 Date: Sun, 3 Sep 2006 14:00:23 +0000 (UTC) Message-ID: References: <44F95E3E.9000708@gentoo.org> <44F96559.6010003@gentoo.org> <44F96881.90806@gentoo.org> <44F98E43.5040307@gentoo.org> <46059ce10609021529q2ccf2db0k22666f295f287824@mail.gmail.com> <46059ce10609021623p629ff47ye2842718d0829529@mail.gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-97-209.ph.ph.cox.net User-Agent: pan 0.110 (Beable Beable) Sender: news X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Status: No, score=-2.558 required=5.5 tests=[AWL=0.041, BAYES_00=-2.599] X-Spam-Score: -2.558 X-Spam-Level: X-Archives-Salt: f2b58f84-830b-4a7c-a097-65d3b818ebb3 X-Archives-Hash: 0216af626e1c8e030915ac2d9d1ccf91 "Dan Meltzer" posted 46059ce10609021623p629ff47ye2842718d0829529@mail.gmail.com, excerpted below, on Sat, 02 Sep 2006 19:23:31 -0400: >> > The gcc-4.1 stabilization bug has been open for a month and a half. >> >> > Thats fairly good notice... >> >> Only to the folks who knew about that bug. For the wider community >> ... it's not notice. > > The wider community will not be effected until they manually make the > switch to 4.1, just like any other gcc upgrade. Before doing this one > would assume they would do a little research. What about the fresh install community? I remember having a /terrible/ time with my first install, 2004.0. At that point I didn't know how much was me and how much was Gentoo so I didn't feel free to file bugs and didn't know how to look for them either. Eventually, it became apparent that 2004.1 was coming soon (quarterly releases that year), so I stuck things on hold for a couple weeks or a month and tried the (still pre-release IIRC) 2004.1, which finally worked. To date, I'm still not sure whether it was me learning more about Gentoo or a better release, but I had spend quite a bit of time on the various lists even before trying 2004.0, enough time to know to avoid things like etc-updating fstab (thankfully, a problem no longer with us), well more time than the regular user can/will/does spend. At install time, it's only logical to go with the newest stable (or ~arch if you are like me) gcc, and Gentoo newbies, rightly or wrongly, will expect it to compile the latest stable version of whatever they want to install. The point about the wider Gentoo community not being affected until they manually switch to the new compiler is certainly valid for the pre-existing community, 100% agree there, but it's the newbies, those least equipped to deal with problems, that get it in the head with what to them may be the ton of bricks that means they fail at their one and only ever attempt at installing Gentoo, and badmouth it from then on, as something only uber-elite hackers can use. (Not that a /bit/ of that from time to time wouldn't be a good thing, in terms of getting only those willing to put the time and energy into learning the system, but that only the uber-elite can do it is false, as long as one is willing to invest the time in learning the system.) >> > Warnings have also appeared on >> > planet.gentoo.org, and in the GWN. >> >> Tsunam posted that there was a push on to get gcc-4.1 stable, but >> there was no target date, and no firm statement that said it would >> definitely be happening. He posted this on July 19th. >> >> The GWN warning was last week. >> >> My apologies, but I've been unable to find an announcement on -dev. > > I do not know if there was on on -dev, I remember hearing for a little > while now that 2006.1 was going to be gcc-4.1.1, but I don't remember > if I read that or heard it in the -x86 irc channel, it may have been > there which doesn't really count :) Beyond the stabilization warnings > however, I would think that gcc-4.1.1 entering unstable (which had a > number of announcements IIRC) should be warning to all users that it > was now on track to be stable, and to be prepared. > > I really do not see what kind of further warning was necessary or even > possible... maybe I'm missing something. (Other than the > yet-to-be-implemented GLEP42 of course) Agreed. IMO, the unmasking to unstable, given the 30-day policy, should have served notice of intent to stabilize. However, for whatever reason and the finger can be pointed several different ways but it doesn't matter as it was the Gentoo /team/ that failed, there remained a rather larger than one would hope number of packages whose last stable version wouldn't compile with the last stable version of gcc, leaving the first-time Gentoo installer with little hint as to what was going on. Having been there myself, that's a bit bewildering and overwhelming! Now, I'm normally pushing the leading/bleeding edge myself, and was routinely eselect compiler setting between the still masked gcc-4.0 and the supported gcc-3.x when necessary, as soon as 4.0 was out. I know how to do that stuff now and take advantage of it, so I'd be (and am) very happy that gcc 4.1.1 stabilized. Realistically, however, I'd suggest that if we had to, to make that newbie install a bit smoother with the new release, we should have delayed the 2006.1 release a few weeks. Pre-release, whether delayed or ideally given the warning time we had since the move to unstable, at minimum, packages whose last stable version was known not to compile with gcc4, should have had an eerror to that effect inserted in the ebuild. An example that came up on the amd64 list would be timidity++, http://bugs.gentoo.org/show_bug.cgi?id=145669 . There's a changelog entry adding a gcc4 patch, but it's to the -r2 version in unstable, where the latest stable is the -r0 version. New user or experienced user, if they try to merge the latest stable timidity++ with the latest stable gcc, it won't work, and it's a known issue. Preferably, the -r2 should have stabilized. I know I have it merged on a ~amd64 system but don't know if it works on a stable system, and suggested to the OP on the amd64 list, that they add it to package.keyword and add a comment on the above bug if it worked for them on an otherwise stable system. If it's not possible to stabilize the -r2 version, however, an eerror displayed in the stable -r0 version when an attempt to compile it with gcc-4 would at least give the user a clue. Now for the practical suggestion. How hard would it be to implement an eclass (or add it to eutils or whatever) that took the last version of gcc (or make it generic enough to work with binutils and the like too, if desired) known to work as a parameter, tested what gcc was being used, and (by second parameter) issued an ewarn or eerror if the presently configured gcc either wasn't tested (ewarn) or was known to fail (eerror)? Perhaps as an optional third parameter would trigger a mention of package.keyword to try an unstable version known to work. Maybe it's partly already implemented? With a standardized eclass solution, it could then be routine to inherit the eclass and do the test, normally at the ewarn level, if a newer than tested gcc was in use. Users, including new first-time-install users would then at least have a clue what went wrong, and what to do to fix it. In a situation such as we just had, then, when a release is coming just after a big gcc upgrade stabilization, it could be accepted practice to allow other than the maintaining dev to do at least the minimum necessary, flip on the eerror trigger with the gcc version set accordingly. Various arch teams or QA or even the toolchain team could then do this if they weren't comfortable keywording the new version ahead of the maintaining arch, and it wouldn't affect the rest of the ebuild so wouldn't be considered trampling on the maintaining dev's territory. Cooperation with the maintaining dev would of course be encouraged, with courtesy notification an accepted minimum if cooperation isn't happening. The effect of the above would be that all the packages for those remaining open bugs connected to the gcc-4.1.1 stabilization would have at minimum an eerror explaining the problem to anyone trying to merge them, and the Hobson's choice between holding up the gcc stabilization and release, and stabilization/release with open bugs and the resulting bewildered new users with no clue whether it was them or Gentoo or what, wouldn't occur. (And yes, I know I gave an alternative, meaning it's not an absolute Hobson's choice, but the implication is that the second one shouldn't happen or be a choice at all.) -- 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