Gentoo Archives: gentoo-amd64

From: Miguel Filipe <miguel.filipe@×××××.com>
To: gentoo-amd64@l.g.o
Subject: Re: [gentoo-amd64] ~* or -* Keyworded packages (cannot force install of "-*" GCC4)
Date: Fri, 23 Dec 2005 19:55:44
Message-Id: f058a9c30512231153x767c50cft2baf50faba5c767f@mail.gmail.com
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

Replies