[gentoo-dev] Re: Portage: missing pieces

[Molle Bestefich]

Richard Fish wrote:
> The expectation here is that when a new version of gcc is stabilized,
> that users will upgrade to that in a reasonable amount of time, and
> use that (by selecting it with gcc-config) for compiling all new
> updates.  FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the
> current stable is 3.4.6-r1 since May 29th.

I don't see how that information is conveyed to the user.  Portage
shouts about upgrading to a new profile from time to time, but it
never tells anyone to upgrade GCC.  Perhaps it should, if that's what
the devs expect people to do.

> The devs can *not* be expected to verify that all software in portage
> builds with all versions of gcc in portage.

Of course not.

> The alternative here is that old versions of gcc disappear from
> portage, but that causes a problem for those who need those versions
> for some reason, such as compiling non-gentoo software.

Yes, ok.  That's a bad alternative.  Thus it seems that there's no
appropriate mechanism to handle new GCC versions in Portage, which
again makes sense wrt. the complaints.

> > Nothing personal against Jakub Moc who probably has a lot to do, but
> > the handling of relevant issues raised in the bugzilla is just
> > unacceptable.
>
> What, exactly, do you find unacceptable in
> "Your gcc version is outdated and unsupported"?

Nothing?
I find it unacceptable that the bug is marked INVALID when it clearly
describes a relevant issue.

As far as I can tell, the complaints are about Portage being unable to
handle GCC upgrades gracefully for end users.

You could perhaps argue that the issue started out as "why do I get
this error message" and ended up being "why doesn't Portage handle GCC
upgrades gracefully", which is of course a slightly different thing.
But it should be clear to anyone reading the bug what the real issue
is.  I'm even willing to bet that if I create a new bug describing the
Portage issue, with no mention of the specific xine ebuild, it will
get closed as a duplicate of this bug anyway.  I've got case studies
proving that this is what happens, heh.

> I suppose portage could be enhanced to have a is_gcc_version_supported()
> check, but I'm not sure how useful that would be.

If that would enable ebuild maintainers to flag xine as requiring 3.4
for compilation, then that would definitely solve the issue described
in the bug.  I'd say that's _very useful_ to the end user.

You could argue that only a couple of people has spent the time to
create a bugzilla login and lodge a complaint in the bug, but there's
probably more out there.  We can count the duplicates in a couple of
months and see ;-).  And as newer GCC features are used throughout,
the situation will probably happen more in the future.

> > What's the state of Portage and Gentoo in general?  Is there not
> > enough hands to do a proper job?  Or is it just that none of the devs
> > see what's wrong because bugs are wrongly being closed marked
> > "INVALID" such as the above when they're in fact not?
>
> If you want to test compiling every version of every package in
> portage with all 21 versions (16 if you assume all -rX versions are
> compatible, or /only 9/ if you only consider stable x86 versions) of
> gcc that are currently in portage, and submit patches when things
> fail, go ahead.

That won't be necessary.  Things mostly works, and when they don't,
users file a bug like the aforementioned one, which should result in
that particular ebuild getting fixed, instead of the bug being marked
INVALID.
-- 
gentoo-dev@g.o mailing list