[gentoo-dev] Re: Gentoo 2006.1

["Duncan" <1i5t5.duncan@cox.net>]

"Dan Meltzer" <parallelgrapefruit@gmail.com> 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