1 |
First of all, thanks for the reply and clarification. It's always good to |
2 |
hear from an actual developer when I start ranting. [I know I could |
3 |
always go pick a fight on gentoo-dev, but I'll reserve that for when I've |
4 |
got a justifiable beef, and not just a half-baked rant. ;)] |
5 |
|
6 |
On Friday 24 February 2006 11:31, Ciaran McCreesh <ciaranm@g.o> |
7 |
wrote about 'Re: [gentoo-user] What happens with masked packages?': |
8 |
> Top level package.mask means there's something wrong with the upstream |
9 |
> package. Often this is because it's a beta release. It can also be used |
10 |
> for major ebuild changes. |
11 |
|
12 |
Okay, that's clearer, though I still wish "beta" was more cleanly separated |
13 |
from "broken" -- While betas generally are broken to some degree, they are |
14 |
purposely put out there so users will file the bugs upstream. |
15 |
|
16 |
While I suppose the comments in package.mask do provide a method for |
17 |
determining when it's "safe" to unmask a beta, it's difficult to |
18 |
automatically handle betas. Under my system you just set |
19 |
ACCEPT_UPSTREAM="BETA" and you get beta packages without the broken ones, |
20 |
automatically. |
21 |
|
22 |
> ~arch means a package is a candidate for going into arch after further |
23 |
> testing, if said testing does not turn up new bugs. This means that |
24 |
> both the ebuild *and* the package should be likely to be stable. |
25 |
|
26 |
So, betas shouldn't ever be ~arch? Or is your definition of stable broad |
27 |
enough to include betas? |
28 |
|
29 |
> -* means the package is in some way architecture or hardware |
30 |
> independent (e.g. a binary only package), and so will only run on archs |
31 |
> that are explicitly listed. |
32 |
|
33 |
So, I guess glibc-2.3.6-r3.ebuild is using -* incorrectly? |
34 |
|
35 |
> Any package setting KEYWORDS="-*" and nothing else is abusing -*, and |
36 |
> will flag a warning on the QA checkers. |
37 |
|
38 |
You mean like gcc-4.1.0_pre20060219.ebuild? |
39 |
|
40 |
Sorry if I come off too critically [1]. I do see an unclean separation of |
41 |
upstream-stable vs. ebuild-stable in the portage system and I'd like to |
42 |
see it fixed, but everyday I appreciate how much work goes in to |
43 |
maintaining the portage tree and improving the gentoo experience. |
44 |
|
45 |
-- |
46 |
Boyd Stephen Smith Jr. |
47 |
bss03@××××××××××.com |
48 |
ICQ: 514984 YM/AIM: DaTwinkDaddy |
49 |
|
50 |
[1] Also, sorry I'm just a squeaky wheel instead of actively trying to fix |
51 |
the problem, I know there are more constructive things to do (GLEP, |
52 |
experimental portage backages, etc.) besides rant on the user list. |
53 |
-- |
54 |
gentoo-user@g.o mailing list |