1 |
Hi all, |
2 |
|
3 |
Thanks for the reply! |
4 |
|
5 |
On 12/23/05, Simon Stelling <blubb@g.o> wrote: |
6 |
> |
7 |
> Hi, |
8 |
> |
9 |
> Miguel Filipe wrote: |
10 |
> > I've been trying to emerge gcc 4.0.2-r2, messing with |
11 |
> > /etc/portage/package.unmask & /etc/portage/package.keywords |
12 |
> > without success.. |
13 |
> > |
14 |
> > the portage man page says that if a package has -* is know to be broken |
15 |
> > on all arches otherwise mentioned. |
16 |
> > So is 4.0.1, 4.0.0, 4.1-snapshot.. |
17 |
> > |
18 |
> > I would expect it to be at least marked unstable "~amd64 .." |
19 |
> |
20 |
> I hope you really know what you are doing (or trying to do). gcc-4.0 isn't |
21 |
> broken, but it is hard-masked because there are *major* changes, meaning |
22 |
> you |
23 |
> should rebuild your whole system with it once you upgraded. That's why it |
24 |
> is not |
25 |
> yet ~amd64 and we want to give it a long testing period. Another issue is |
26 |
> that |
27 |
> gcc-4.0 is even stricter than 3.4, meaning lots of packages won't build |
28 |
> anymore. |
29 |
> That's why we marked it -*, because we don't want to disappoint normal |
30 |
> users who |
31 |
> aren't familiar with writing patches. And those who are, are clever enough |
32 |
> to |
33 |
> unmask a hard masked package, it's not that hard after all. |
34 |
|
35 |
|
36 |
|
37 |
My situation is the following: |
38 |
- I'm aware of the diferences. |
39 |
- I'm used to recurring to gcc-config for switching between compiler |
40 |
versions. |
41 |
- I'm a software developer and _need_ gcc4 for development & testing my |
42 |
project's code (I for one, need to have gcc4 to make shure my code is gcc4 |
43 |
compatible :) ) |
44 |
- I'm aware of /etc/portage/package.* files, and respective man pages :) |
45 |
- The machine is a testing machine, has to be kind of stable, but I allready |
46 |
hand pick a couple of ~amd64 (cmucl, sbcl, java, gcc ..some others). |
47 |
|
48 |
My main gripe is that I simply cannot install gcc4.0.2-r2.., here's what I |
49 |
tried...: |
50 |
---- |
51 |
miguel@feynman ~ $ sudo fgrep gcc /etc/portage/package.* |
52 |
/etc/portage/package.keywords:# gcc4 |
53 |
/etc/portage/package.keywords:sys-devel/gcc -* |
54 |
/etc/portage/package.unmask:=sys-devel/gcc-4.0.2-r2 |
55 |
miguel@feynman ~ $ sudo fgrep KEYWORDS /usr/portage/sys-devel/gcc/gcc- |
56 |
4.0.2-r2.ebuild |
57 |
KEYWORDS="-*" |
58 |
miguel@feynman ~ $ emerge gcc -pv |
59 |
|
60 |
These are the packages that I would merge, in order: |
61 |
|
62 |
Calculating dependencies ...done! |
63 |
[ebuild R ] sys-devel/gcc-3.4.4-r1 (-altivec) -bootstrap |
64 |
-boundschecking* -build +fortran -gcj +gtk -hardened -ip28 -mudflap |
65 |
(-multilib) -multislot (-n32) (-n64) +nls -nocxx -nopie -nossp -objc |
66 |
-objc-gc -vanilla 46 kB |
67 |
|
68 |
Total size of downloads: 46 kB |
69 |
miguel@feynman ~ $ ACCEPT_KEYWORDS="-*" emerge =sys-devel/gcc-4.0.2-r2 -pv |
70 |
|
71 |
These are the packages that I would merge, in order: |
72 |
|
73 |
Calculating dependencies |
74 |
!!! All ebuilds that could satisfy "=sys-devel/gcc-4.0.2-r2" have been |
75 |
masked. |
76 |
!!! One of the following masked packages is required to complete your |
77 |
request: |
78 |
- sys-devel/gcc-4.0.2-r2 (masked by: -* keyword) |
79 |
|
80 |
For more information, see MASKED PACKAGES section in the emerge man page or |
81 |
refer to the Gentoo Handbook. |
82 |
|
83 |
miguel@feynman ~ $ emerge =sys-devel/gcc-4.0.2-r2 -pv |
84 |
|
85 |
These are the packages that I would merge, in order: |
86 |
|
87 |
Calculating dependencies |
88 |
!!! All ebuilds that could satisfy "=sys-devel/gcc-4.0.2-r2" have been |
89 |
masked. |
90 |
!!! One of the following masked packages is required to complete your |
91 |
request: |
92 |
- sys-devel/gcc-4.0.2-r2 (masked by: -* keyword) |
93 |
|
94 |
For more information, see MASKED PACKAGES section in the emerge man page or |
95 |
refer to the Gentoo Handbook. |
96 |
--- |
97 |
|
98 |
Conclusion: cannot selectively (force) install gcc4.0.2 |
99 |
|
100 |
Solution: editing the ebuild, and adding a "~amd64", but I guess that the |
101 |
porpuse /etc/portage/package.* infrastructure is to avoid that. |
102 |
I also think that I had ocasions where editing the ebuild would prevent |
103 |
form emerging that same ebuild (some kind of ebuild tampering prevention). |
104 |
|
105 |
|
106 |
|
107 |
|
108 |
> gentoo seems to have major problems in keeping up with the public |
109 |
> > releases.. its starting to look like debian stable.... |
110 |
> |
111 |
> Is this a 'i want to help'? |
112 |
|
113 |
|
114 |
|
115 |
I have contributed in the early start (before 1.0), and after that with bug |
116 |
squashing, but nothing impressive (quality or quantity wise). But simply, I |
117 |
don-t have time to nurse my install.. I wan't it to work.. that why I'm |
118 |
following amd64 stable + very few cherry picked ~amd64. |
119 |
|
120 |
|
121 |
|
122 |
|
123 |
> also.. I don't see the point in having 3 types of tags: stable, |
124 |
> > unstable, broken.. maybe the same point of (stable, testing, unstable.. |
125 |
> > ala debian) |
126 |
> |
127 |
> You're mixing up quite unrelated things. -* is generally used for packages |
128 |
> that |
129 |
> are only available for one or two arch (typical example: binary packages). |
130 |
> When |
131 |
> it means 'broken', then it is only in the tree because it makes it easier |
132 |
> for |
133 |
> devs to share ebuilds which they (and of course the 'advanced' users) can |
134 |
> test. |
135 |
|
136 |
|
137 |
|
138 |
Okay, that makes sense. |
139 |
|
140 |
|
141 |
> Nevermind, basically, I'm using gentoo since 1.0rc6 and starting to be |
142 |
> > disapointed by the slowness of having fresh software available.. |
143 |
> |
144 |
> If you feel more adventurous, use package.(unmask|keywords). It's a |
145 |
> wonderful |
146 |
> tool to let the user decide himself what is stable enough for him. |
147 |
|
148 |
|
149 |
|
150 |
doing that allready. |
151 |
|
152 |
|
153 |
> gnome 2.12 came out 7 of september, maybe when gnome 2.14 is out I can |
154 |
> > find it keyworded "amd64".. |
155 |
> |
156 |
> Again, package.keywords if you agree. Since 1.0rc6, Gentoo has changed a |
157 |
> lot. |
158 |
> We've got a huge user base, and we really don't feel like getting the same |
159 |
> bug |
160 |
> reported 10 times just because we marked some untested piece of software |
161 |
> stable. |
162 |
> It won't make most users very happy either, especially those who want a |
163 |
> system |
164 |
> that 'just works'. |
165 |
> |
166 |
> > In conclusion, package mantainance needs a new organizational way to |
167 |
> scale.. |
168 |
> > Or should I simply move to ~amd64, just like any debian user sets its |
169 |
> > system to testing without thinking twice, just after the install. |
170 |
> |
171 |
> Moving to ~amd64 could be the right thing for you. But if you're running |
172 |
> ~amd64 |
173 |
> and get tons of bugs, don't bitch. Personally, I think everybody who runs |
174 |
> ~amd64 |
175 |
> should be filing bugs whenever he hits one. If you don't want to do that, |
176 |
> keep |
177 |
> your system stable. |
178 |
> |
179 |
> Regards, |
180 |
> |
181 |
> -- |
182 |
> Simon Stelling |
183 |
> Gentoo/AMD64 Operational Co-Lead |
184 |
> blubb@g.o |
185 |
> -- |
186 |
> gentoo-amd64@g.o mailing list |
187 |
> |
188 |
> |
189 |
|
190 |
|
191 |
-- |
192 |
Miguel Sousa Filipe |