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