1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
|
5 |
On Sep 4, 2005, at 10:01 PM, Finn Thain wrote: |
6 |
|
7 |
>> Uh, no? The x11-libs/qt deps are indeed correct. Please do your |
8 |
>> homework |
9 |
>> before posting to this list; you should read up on Gentoo policy |
10 |
>> about |
11 |
>> DEPENDS and packages that are in 'system', such as baselayout. |
12 |
>> |
13 |
> |
14 |
> If that is the case, shouldn't qt be hard masked? If you move |
15 |
> everything |
16 |
> from arch to ~arch, you will be doing a lot more of that. |
17 |
|
18 |
I don't think you understand the difference between arch and ~arch, |
19 |
nor the use of package.mask. QT is marked ~arch for several reasons |
20 |
1) it compiles and works on multiple unstable systems, 2) it has not |
21 |
been tested against a stable environment and has not been bug-free |
22 |
for 30 days, thus it cannot be "arch". If you wish to try to use a |
23 |
~arch package on an arch system, that's fine. Just don't yell when it |
24 |
breaks. |
25 |
|
26 |
> |
27 |
> |
28 |
>> Should Gentoo policy change, I would have absolutely no problem (and |
29 |
>> would actually encourage) adding 'virtual/baselayout' to DEPENDS |
30 |
>> where |
31 |
>> necessary. Brian Harring has also discussed this on gentoo-dev, in |
32 |
>> relation to 'BDEPENDS'. |
33 |
>> |
34 |
>> |
35 |
>>> Well, moving stable packages to testing also creates a misnomer. |
36 |
>>> |
37 |
>> |
38 |
>> Again, do your homework. Stable packages are a subset of testing |
39 |
>> packages for any given arch. By specifying '~arch' in your |
40 |
>> KEYWORDS (in |
41 |
>> /etc/make.conf), you are actually implicitly specifying 'arch'. |
42 |
>> |
43 |
> |
44 |
> This is nonsense. There are some packages that are keyworded arch |
45 |
> for a |
46 |
> reason. i.e. they are different than those keyworded ~arch. |
47 |
|
48 |
Actually, they're not different. The packages are exactly the same. |
49 |
"arch" designates that the package has been sufficiently tested and |
50 |
bug-free for long enough to be considered "stable". |
51 |
|
52 |
> If you are |
53 |
> saying that there is no difference, maybe you should do some homework. |
54 |
|
55 |
... |
56 |
|
57 |
> I |
58 |
> really don't think the semantic problems here are worth pursuing. |
59 |
> If there |
60 |
> is a problem with calling certain ebuilds "stable", that is because |
61 |
> there |
62 |
> are bugs. So what? At least once a month I find a new bug in |
63 |
> 10.3.9, which |
64 |
> I installed when it was released. |
65 |
|
66 |
Then in my understanding of proper QA, 10.3.9 should not be "stable" |
67 |
either. Seriously though, we have a lot more bugs. I am not |
68 |
comfortable saying something is stable when it is clearly buggy. |
69 |
|
70 |
>>> Can someone explain what is to be gained from this that cannot be |
71 |
>>> achieved with automated builds (e.g. to weed out the badly broken |
72 |
>>> stable packages and check the deps of the ~ppc-macos packages); |
73 |
>>> as well |
74 |
>>> as a policy to relax the "30 day" rule? |
75 |
>>> |
76 |
>> |
77 |
>> What automated builds? AFAIK, we don't have an automated build |
78 |
>> system, |
79 |
>> and one won't exist for a Real Long Time(tm). Once it does, I'm |
80 |
>> all for |
81 |
>> keeping a stable branch. Until then, I find that keeping a stable |
82 |
>> branch |
83 |
>> is way more work than we can keep up with, for all the reasons |
84 |
>> cited in |
85 |
>> my previous message(s) to this list. |
86 |
>> |
87 |
> |
88 |
> And I explained how to avoid pressure to "keep up", in my previous |
89 |
> messages. As yet, no one has responded the questions and concerns |
90 |
> raised |
91 |
> there-in. |
92 |
|
93 |
Sure, an automated system is a great idea. The problem is that it |
94 |
requires a lot of work to build one. It is in the works for now, but |
95 |
it's not here yet, so until then we have to deal with what we've got. |
96 |
Once we have an automated system and our setup isn't as dynamic, we |
97 |
can easily add support for a stable configuration. |
98 |
|
99 |
- --Lina Pezzella |
100 |
Ebuild & Porting Co-Lead |
101 |
Gentoo for OS X |
102 |
|
103 |
-----BEGIN PGP SIGNATURE----- |
104 |
Version: GnuPG v1.4.2 (Darwin) |
105 |
|
106 |
iD8DBQFDG7qXNJ9STR9DbYERAv4uAJ9uMgXW9MNrUidztGeEgFUmk0YNJwCfe97I |
107 |
oVh0UxOAIEBd1/QDneSsK9g= |
108 |
=/+Uo |
109 |
-----END PGP SIGNATURE----- |
110 |
-- |
111 |
gentoo-osx@g.o mailing list |