1 |
On Sun, 4 Sep 2005, Lina Pezzella wrote |
2 |
> |
3 |
> On Sep 4, 2005, at 10:01 PM, Finn Thain wrote: |
4 |
> |
5 |
> > >Uh, no? The x11-libs/qt deps are indeed correct. Please do your |
6 |
> > >homework before posting to this list; you should read up on Gentoo |
7 |
> > >policy about DEPENDS and packages that are in 'system', such as |
8 |
> > >baselayout. |
9 |
> > > |
10 |
> > |
11 |
> >If that is the case, shouldn't qt be hard masked? If you move |
12 |
> >everything from arch to ~arch, you will be doing a lot more of that. |
13 |
> |
14 |
> I don't think you understand the difference between arch and ~arch, nor |
15 |
> the use of package.mask. QT is marked ~arch for several reasons 1) it |
16 |
> compiles and works on multiple unstable systems, 2) it has not been |
17 |
> tested against a stable environment and has not been bug-free for 30 |
18 |
> days, thus it cannot be "arch". If you wish to try to use a ~arch |
19 |
> package on an arch system, that's fine. Just don't yell when it breaks. |
20 |
|
21 |
Yep, that's pretty much how I understand the difference between arch and |
22 |
~arch. There is no disagreement here, but you missed my point: which |
23 |
is what happens (under your ~arch proposal) when a hypothetical ~arch |
24 |
qt-x.y.z breaks because I'm running a ~arch baselayout (but not the same |
25 |
~arch one used when the dev keyworded qt-x.y.z with ~arch)? What happens |
26 |
is this: qt breaks, i.e. similar bug report to what we have now _unless_ |
27 |
that qt gets hard masked. |
28 |
|
29 |
Abandoning arch deprives you of a useful feature of portage. No-one has |
30 |
indicated how that functionality might be recovered in the future. |
31 |
|
32 |
> > |
33 |
> > >Should Gentoo policy change, I would have absolutely no problem (and |
34 |
> > >would actually encourage) adding 'virtual/baselayout' to DEPENDS |
35 |
> > >where necessary. Brian Harring has also discussed this on gentoo-dev, |
36 |
> > >in relation to 'BDEPENDS'. |
37 |
> > > |
38 |
> > > |
39 |
> > > >Well, moving stable packages to testing also creates a misnomer. |
40 |
> > > > |
41 |
> > > |
42 |
> > >Again, do your homework. Stable packages are a subset of testing |
43 |
> > >packages for any given arch. By specifying '~arch' in your KEYWORDS |
44 |
> > >(in /etc/make.conf), you are actually implicitly specifying 'arch'. |
45 |
> > > |
46 |
> > |
47 |
> >This is nonsense. There are some packages that are keyworded arch for a |
48 |
> >reason. i.e. they are different than those keyworded ~arch. |
49 |
> |
50 |
> Actually, they're not different. The packages are exactly the same. |
51 |
> "arch" designates that the package has been sufficiently tested and |
52 |
> bug-free for long enough to be considered "stable". |
53 |
|
54 |
This is a contradiction in terms. You say, they're not different, yet one |
55 |
can be considered stable and one cannot? |
56 |
|
57 |
Again, you've missed my point (which was purely a response to your |
58 |
complaint about a misnomer, i.e. a semantic issue that really is |
59 |
inconsequential). |
60 |
|
61 |
> >If you are saying that there is no difference, maybe you should do some |
62 |
> >homework. |
63 |
> |
64 |
> ... |
65 |
> |
66 |
> >I really don't think the semantic problems here are worth pursuing. If |
67 |
> >there is a problem with calling certain ebuilds "stable", that is |
68 |
> >because there are bugs. So what? At least once a month I find a new bug |
69 |
> >in 10.3.9, which I installed when it was released. |
70 |
> |
71 |
> Then in my understanding of proper QA, 10.3.9 should not be "stable" |
72 |
> either. Seriously though, we have a lot more bugs. |
73 |
|
74 |
I do take Mac OS X bugs seriously. FWIW, the most recent one I found was |
75 |
an nasty ipfw bug that will never be fixed. |
76 |
|
77 |
> I am not comfortable saying something is stable when it is clearly |
78 |
> buggy. |
79 |
|
80 |
There is no such thing as bug free. There is only "free of known bugs". |
81 |
|
82 |
Now, if you relax the 30-day rule, you just change the definition of |
83 |
"stable" slightly so that it becomes achievable within the limited |
84 |
resources of the project. "Stable" was never anything more than a line in |
85 |
the sand. |
86 |
|
87 |
It might be useful to look at ways minor-architectures (say m68k, s390 or |
88 |
BSD) cope with the limited resources problem. |
89 |
|
90 |
> > > >Can someone explain what is to be gained from this that cannot be |
91 |
> > > >achieved with automated builds (e.g. to weed out the badly broken |
92 |
> > > >stable packages and check the deps of the ~ppc-macos packages); as |
93 |
> > > >well as a policy to relax the "30 day" rule? |
94 |
> > > > |
95 |
> > > |
96 |
> > >What automated builds? AFAIK, we don't have an automated build |
97 |
> > >system, and one won't exist for a Real Long Time(tm). Once it does, |
98 |
> > >I'm all for keeping a stable branch. Until then, I find that keeping |
99 |
> > >a stable branch is way more work than we can keep up with, for all |
100 |
> > >the reasons cited in my previous message(s) to this list. |
101 |
> > > |
102 |
> > |
103 |
> >And I explained how to avoid pressure to "keep up", in my previous |
104 |
> >messages. As yet, no one has responded the questions and concerns |
105 |
> >raised there-in. |
106 |
> |
107 |
> Sure, an automated system is a great idea. The problem is that it |
108 |
> requires a lot of work to build one. It is in the works for now, but |
109 |
> it's not here yet, so until then we have to deal with what we've got. |
110 |
> Once we have an automated system and our setup isn't as dynamic, we can |
111 |
> easily add support for a stable configuration. |
112 |
|
113 |
Automated builds address the QA problem. It is a completely seperate issue |
114 |
which I probably shouldn't have raised in the context of the |
115 |
s/ppc-macos/~ppc-macos/ proposal, simply because that proposal has nothing |
116 |
to do with improving QA. |
117 |
|
118 |
-f |
119 |
|
120 |
> - --Lina Pezzella |
121 |
> Ebuild & Porting Co-Lead Gentoo for OS X |
122 |
-- |
123 |
gentoo-osx@g.o mailing list |