Re: [gentoo-dev] Re: Portage: missing pieces

[Kevin F. Quinn]

On Sun, 9 Jul 2006 23:30:40 +0200
"Molle Bestefich" <molle.bestefich@×××××.com> wrote:

> 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.

It's conveyed by the fact that when updating, you see a new compiler
version being installed.  If you have done a world update, you already
have the later compilers installed.

>  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.

As has been explained before, as far as the gcc ebuilds are concerned
their job is finished when the new compiler version is installed.  It
is up to the user to decide to change their system compiler.  The
gcc ebuild will switch between minor versions if USE=multislot isn't
specified, and in that case will warn the user about ABI breakage if
relevant, as it requires the user to rebuild lots of stuff.

> > 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.

Portage and the ebuilds handle it fine.  All that needs to happen is
for users to accept the advice to read the gcc upgrading guide when
they trip over problems that arise from issues with gcc versions.

> > > 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.

Don't take the bug marking as a personal attack - it's a marking for
devs to understand what was the impact of the bug.  Focus on the advice
given, which from what I can see was succinct and correct.

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

What exactly do you expect to happen?  GCC updates don't switch major
versions automatically, because in general it means changing ABI which
means rebuilding everything.  Where ABI breakage occurs between minor
versions and the compiler is switched automatically, the ebuild issues
a warning when ABI breakage occurs and advises what to do to rebuild
affected packages.

> 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.

If two bugs describe the same issue, regardless of the summary field
one will get marked as a duplicate of the other.  Again, this is not a
personal attack but information for devs to understand whether
different work is needed for the different bugs.

> > 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.

The problem with having the xine ebuild check gcc version and aborting
if a certain version is found active, is that if the gcc version is
modified in the future such that xine would then build with it, that
handling would have to come out again.  Since the ebuild dies either
way, the only difference is that some users may not realise that
upgrading gcc will work - in which case they file a bug and they get
told to upgrade gcc - job done.

> 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.

Another way of looking at it, is that there are a lot of people out
there who are coping just fine with GCC upgrades as they are currently
managed.

> > > 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.

As I said above, don't take the "INVALID" marking personally.  The fact
is that from the perspective of the relevant devs, the resolution of the
bug was to advise the user to upgrade gcc, which meant no change
required to the tree. See
https://bugs.gentoo.org/page.cgi?id=fields.html - as far as devs are
concerned, "The problem described is not a bug" so INVALID is the
correct resolution marking.


-- 
Kevin F. Quinn