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 might install a new GCC, but it doesn't switch to it.
It doesn't tell the user to switch to it, either.
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.
> 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.
> 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.
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.
> 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.
b) Skip package XYZ, but continue updating the rest of the system.
Package XYZ could also block the update, that would be OK.
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.
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.
> > 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.
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?
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.
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.
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.
--
[email protected] mailing list
