1 |
Kevin F. Quinn wrote: |
2 |
> > > The expectation here is that when a new version of gcc is |
3 |
> > > stabilized, that users will upgrade to that in a reasonable amount |
4 |
> > > of time, and use that (by selecting it with gcc-config) for |
5 |
> > > compiling all new updates. FYI, gcc-3.4.4-r1 was stabilized on |
6 |
> > > 2-Dec-2005, and the current stable is 3.4.6-r1 since May 29th. |
7 |
> > |
8 |
> > I don't see how that information is conveyed to the user. |
9 |
> |
10 |
> It's conveyed by the fact that when updating, you see a new compiler |
11 |
> version being installed. If you have done a world update, you |
12 |
> already have the later compilers installed. |
13 |
|
14 |
No, that's not true. It's not conveyed at all. |
15 |
It might install a new GCC, but it doesn't switch to it. |
16 |
It doesn't tell the user to switch to it, either. |
17 |
|
18 |
> As has been explained before, as far as the gcc ebuilds are |
19 |
> concerned their job is finished when the new compiler version |
20 |
> is installed. It is up to the user to decide to change their |
21 |
> system compiler. |
22 |
|
23 |
You seem to have missed the issue. |
24 |
|
25 |
> > Yes, ok. That's a bad alternative. Thus it seems that there's no |
26 |
> > appropriate mechanism to handle new GCC versions in Portage, which |
27 |
> > again makes sense wrt. the complaints. |
28 |
> |
29 |
> Portage and the ebuilds handle it fine. |
30 |
|
31 |
Same. |
32 |
|
33 |
> All that needs to happen is for users to accept the advice to read |
34 |
> the gcc upgrading guide when they trip over problems that arise |
35 |
> from issues with gcc versions. |
36 |
|
37 |
There's no advice, instead Portage crashes during a system update. |
38 |
|
39 |
> > Nothing? |
40 |
> > I find it unacceptable that the bug is marked INVALID when it clearly |
41 |
> > describes a relevant issue. |
42 |
> |
43 |
> Don't take the bug marking as a personal attack |
44 |
|
45 |
I don't, it's not my bug ;-). |
46 |
|
47 |
> it's a marking for devs to understand what was the impact of the bug. |
48 |
|
49 |
It's marked INVALID, while the issue is clearly valid. |
50 |
|
51 |
> Focus on the advice given, which from what I can see was succinct |
52 |
> and correct. |
53 |
|
54 |
It shouldn't even be _necessary_ to create bugs and receive advice |
55 |
from a living, breathing human being just to perform a system update. |
56 |
|
57 |
> > As far as I can tell, the complaints are about Portage being unable to |
58 |
> > handle GCC upgrades gracefully for end users. |
59 |
> |
60 |
> What exactly do you expect to happen? GCC updates don't switch major |
61 |
> versions automatically, because in general it means changing ABI which |
62 |
> means rebuilding everything. |
63 |
|
64 |
Ah, that's a good question. |
65 |
|
66 |
I think the proper reaction from Portage would be (both): |
67 |
a) Alert the user that the newest version of package XYZ cannot be |
68 |
merged because it needs a newer compiler than the currently |
69 |
selected one. |
70 |
b) Skip package XYZ, but continue updating the rest of the system. |
71 |
|
72 |
Package XYZ could also block the update, that would be OK. |
73 |
|
74 |
> Again, this is not a personal attack but information for devs |
75 |
> to understand whether different work is needed for the different bugs. |
76 |
|
77 |
Noone has mentioned personal attacks, so drop that train of thought. |
78 |
|
79 |
You misread my point. I was trying to say that bugs describing problems |
80 |
(with fx. Portage) in abstract will often get closed as a duplicate of a |
81 |
bug where someone has experienced a particular incarnation of the |
82 |
larger problem described. |
83 |
|
84 |
That's a good way to make sure that relevant end user issues never |
85 |
come into contact with the devs, which I'm sure is not what the |
86 |
devs want. |
87 |
|
88 |
> > > I suppose portage could be enhanced to have a |
89 |
> > > is_gcc_version_supported() check, but I'm not sure how useful that |
90 |
> > > would be. |
91 |
> > |
92 |
> > If that would enable ebuild maintainers to flag xine as requiring 3.4 |
93 |
> > for compilation, then that would definitely solve the issue described |
94 |
> > in the bug. I'd say that's _very useful_ to the end user. |
95 |
> |
96 |
> The problem with having the xine ebuild check gcc version and aborting |
97 |
> if a certain version is found active, |
98 |
|
99 |
I don't think anyone would implement it that way, since that's braindead ;-). |
100 |
Instead of checking a particular version, checking for a minimum |
101 |
version would be the default available functionality. |
102 |
|
103 |
> is that if the gcc version is modified in the future such that xine would |
104 |
> then build with it, that handling would have to come out again. |
105 |
|
106 |
In the (hysterically abstract) situation where someone revisits an old |
107 |
version of GCC and adds GCC-4 features, nothing would break. |
108 |
|
109 |
Users would still be told to upgrade to a newer version, and all would |
110 |
be well, despite the fact that the old GCC with the backported feature |
111 |
could now theoretically be used. |
112 |
|
113 |
(But it's just trolling anyway, you're really describing a non-issue, IMHO.) |
114 |
|
115 |
> Another way of looking at it, is that there are a lot of people out |
116 |
> there who are coping just fine with GCC upgrades as they are currently |
117 |
> managed. |
118 |
|
119 |
Uh. What's your point? |
120 |
That you're one of those people who hates change just because it's |
121 |
change, or do you have something more relevant to say that I'm not |
122 |
catching? |
123 |
|
124 |
> See https://bugs.gentoo.org/page.cgi?id=fields.html - as far as devs |
125 |
> are concerned, "The problem described is not a bug" so INVALID is the |
126 |
> correct resolution marking. |
127 |
|
128 |
"Not a bug" does not translate to "Not an issue". |
129 |
You're practicing an extremely narrow view of what's a bug, and that's |
130 |
fine - we'll just call it an issue instead. |
131 |
Next step is to either |
132 |
a) declare that the Gentoo Bugzilla is in fact an issue tracker, or |
133 |
b) decide that problems which does not fit your narrow view of a |
134 |
"bug" belongs on a mailing list. |
135 |
|
136 |
Either way is fine, someone just needs to decide where more abstract |
137 |
issues should be archived - in the bugzilla or in the mailing |
138 |
list(s)'s archives. |
139 |
|
140 |
In case of b), fields.html should be modified to |
141 |
1) include your narrow view of what's-a-bug-and-what's-not (see |
142 |
INVALID), the current description doesn't do. |
143 |
2) tell people to take problems which doesn't fit that view to the |
144 |
mailing list(s). |
145 |
|
146 |
A good place to end this bug-or-not branch of the discussion which |
147 |
you've delved into would IMHO be if you could create a good |
148 |
description/explanation to use with bullet 1). I know it's not easy, |
149 |
which is probably why most people go with something like solution a, |
150 |
heh, but I'm sure it can be done with some hard thinking. It seems to |
151 |
me that that's the only way to actually validate your point. |
152 |
-- |
153 |
gentoo-dev@g.o mailing list |