Gentoo Archives: gentoo-osx

From: Finn Thain <fthain@××××××××××××××××.au>
To: gentoo-osx@l.g.o
Subject: Re: [gentoo-osx] on stable and unstable ppc-macos
Date: Mon, 05 Sep 2005 04:41:17
Message-Id: Pine.LNX.4.63.0509051420180.3912@loopy.telegraphics.com.au
In Reply to: Re: [gentoo-osx] on stable and unstable ppc-macos by Lina Pezzella
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