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

[Kevin F. Quinn]

On Mon, 10 Jul 2006 19:23:54 +0200
"Molle Bestefich" <molle.bestefich@×××××.com> wrote:

> Kevin F. Quinn 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.
>
> No, that's not true.  It's not conveyed at all.

It is clear that a new version of GCC is installed.  It is also clear
that it is not switched to (otherwise the upgrade would have to trundle
off and rebuild everything - we'd be swamped with complaints if we did
that!).

> It might install a new GCC, but it doesn't switch to it.

By design.

> It doesn't tell the user to switch to it, either.

Again by design.

It's up to the user to switch to a different compiler, should they wish
to.  In other words, it's a user choice which compiler version they use.

> > 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.
>
> You seem to have missed the issue.

Maybe, that wasn't my point.  I'm telling you what the situation re.
compiler installation actually is, and how it is designed to be.


> > > 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.
>
> Same.
>
> > 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.
>
> There's no advice, instead Portage crashes during a system update.

The advice is to switch to a more recent compiler.  Jakub has made that
clear on the bug, and we've said it several times here.  As a result,
there is no change to be done to any ebuilds etc.


> > > 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
>
> I don't, it's not my bug ;-).
>
> > it's a marking for devs to understand what was the impact of the
> > bug.
>
> It's marked INVALID, while the issue is clearly valid.

OK; one more time.  The bug does not lead to any change to anything in
the tree.  Therefore it is marked INVALID, in that it is not a valid
issue with respect to the Gentoo tree.  INVALID has the meaning
ascribed to it on the bugzilla help page, not the meaning from an
English dictionary.  When a bug is fixed, something has to change for
that fix to happen - if there's no change, either there's a
bug that we won't fix (WONTFIX) or there's no bug.  In this case
there's no bug, in my opinion.

> > Focus on the advice given, which from what I can see was succinct
> > and correct.
>
> It shouldn't even be _necessary_ to create bugs and receive advice
> from a living, breathing human being just to perform a system update.

You have to realise that being a constantly moving source distribution,
it is impossible to ensure that all packages in all stable versions
interoperate in all possible combinations.  We don't guarantee that.
We do go to some effort to ensure all latest stable versions
interoperate when built sensibly, when it comes to a release - that's as
far as we can go, realistically.


> > > 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.
>
> Ah, that's a good question.
>
> I think the proper reaction from Portage would be (both):
>  a) Alert the user that the newest version of package XYZ cannot be
>     merged because it needs a newer compiler than the currently
>     selected one.

I explained above why this wouldn't be a good idea.

>  b) Skip package XYZ, but continue updating the rest of the system.

emerge --resume --skipfirst

> Package XYZ could also block the update, that would be OK.

The problem with this is the same as with (a).

> > Again, this is not a personal attack but information for devs
> > to understand whether different work is needed for the different
> > bugs.
>
> Noone has mentioned personal attacks, so drop that train of thought.
>
> You misread my point.  I was trying to say that bugs describing
> problems (with fx. Portage) in abstract will often get closed as a
> duplicate of a bug where someone has experienced a particular
> incarnation of the larger problem described.

(Just to clarify - "portage" refers to the application
sys-apps/portage, which you use to install stuff from the tree of
ebuilds, often referred to as the "portage tree")

> That's a good way to make sure that relevant end user issues never
> come into contact with the devs, which I'm sure is not what the
> devs want.

When a bug is marked as a duplicate, a comment is added automatically
to that bug indicating which bug it is being marked a duplicate of.
Also, the reporter of the duplicate bug is added to the CC list of the
original bug.  In this way, the reporter is integrated into the
communication chain for the original bug, where they can read back
through the history, comment, receive bug data from devs actioning the
bug etc.  So your point 


> > > > 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,
>
> I don't think anyone would implement it that way, since that's
> braindead ;-). Instead of checking a particular version, checking for
> a minimum version would be the default available functionality.
>
> > 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.
>
> In the (hysterically abstract) situation where someone revisits an old
> version of GCC and adds GCC-4 features, nothing would break.

You would be surprised; fixes from later versions are often back-ported
to older versions (especially when upstream do so).


> Users would still be told to upgrade to a newer version, and all would
> be well, despite the fact that the old GCC with the backported feature
> could now theoretically be used.
>
> (But it's just trolling anyway, you're really describing a non-issue,
> IMHO.)
>
> > 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.
>
> Uh.  What's your point?
> That you're one of those people who hates change just because it's
> change, or do you have something more relevant to say that I'm not
> catching?

My point is that you imply this issue is a problem for many users - a
point you snipped so I'm pasting it again here:

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

My point is that from what we can see, it isn't a problem for many
users.

> > 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.
>
> "Not a bug" does not translate to "Not an issue".
> You're practicing an extremely narrow view of what's a bug, and that's
> fine - we'll just call it an issue instead.
> Next step is to either
>  a) declare that the Gentoo Bugzilla is in fact an issue tracker, or
>  b) decide that problems which does not fit your narrow view of a
> "bug" belongs on a mailing list.

We consider bug and issue to be the same thing, as far as Gentoo
Bugzilla is concerned.  Gentoo bugzilla is there to track any problem
a user might have with Gentoo.  Clearly there are times when the user
just has to follow some simple instructions to sort out their system
without any change needed to the tree.  In these cases we mark the
bugs FIXED/INVALID.  My point is that the bug is resolved without
needing any change to the portage tree - therefore it is marked
INVALID.  Whether you call the reports bugs, issues, tickets whatever is
irrelevant.

> Either way is fine, someone just needs to decide where more abstract
> issues should be archived - in the bugzilla or in the mailing
> list(s)'s archives.

We track all issues in Gentoo Bugzilla, be they bugs, enhancement
requests, whatever.  Many times a bug is raised that is resolved
without needing any change to the tree - in that case we mark it
RESOLVED/INVALID.  If we wanted to be warm and fuzzy about it, we could
change the INVALID to NOT-A-BUG (which is what GNU do) or perhaps if we
want to be really cuddly we could try "NOCHANGE".  Personally I don't
think it's worth the effort.

> In case of b), fields.html should be modified to
>  1) include your narrow view of what's-a-bug-and-what's-not (see
> INVALID), the current description doesn't do.
>  2) tell people to take problems which doesn't fit that view to the
> mailing list(s).
>
> A good place to end this bug-or-not branch of the discussion which
> you've delved into would IMHO be if you could create a good
> description/explanation to use with bullet 1).  I know it's not easy,
> which is probably why most people go with something like solution a,
> heh, but I'm sure it can be done with some hard thinking.  It seems to
> me that that's the only way to actually validate your point.

A good place to end it is here, because it is of no value to pursue it
further.


-- 
Kevin F. Quinn