| 1 |
On Sun, 4 Sep 2005, Hasan Khalil wrote: |
| 2 |
|
| 3 |
> |
| 4 |
> On Sep 4, 2005, at 24:00, Finn Thain wrote: |
| 5 |
> |
| 6 |
> >Are there known bugs with the ~ppc-macos baselayout? |
| 7 |
> |
| 8 |
> Yes and no. There are design issues still in the works with it. I think |
| 9 |
> that the general consensus is that it's definitely _not_ ready for |
| 10 |
> prime-time, yet. |
| 11 |
> |
| 12 |
> >Yes, and if devs used stable, that would improve QA also. If the dev |
| 13 |
> >that keyworded qt was using stable, s/he would have found that the qt |
| 14 |
> >deps were wrong because they don't include the baselayout requirement. |
| 15 |
> |
| 16 |
> Uh, no? The x11-libs/qt deps are indeed correct. Please do your homework |
| 17 |
> before posting to this list; you should read up on Gentoo policy about |
| 18 |
> DEPENDS and packages that are in 'system', such as baselayout. |
| 19 |
|
| 20 |
If that is the case, shouldn't qt be hard masked? If you move everything |
| 21 |
from arch to ~arch, you will be doing a lot more of that. |
| 22 |
|
| 23 |
> Should Gentoo policy change, I would have absolutely no problem (and |
| 24 |
> would actually encourage) adding 'virtual/baselayout' to DEPENDS where |
| 25 |
> necessary. Brian Harring has also discussed this on gentoo-dev, in |
| 26 |
> relation to 'BDEPENDS'. |
| 27 |
> |
| 28 |
> >Well, moving stable packages to testing also creates a misnomer. |
| 29 |
> |
| 30 |
> Again, do your homework. Stable packages are a subset of testing |
| 31 |
> packages for any given arch. By specifying '~arch' in your KEYWORDS (in |
| 32 |
> /etc/make.conf), you are actually implicitly specifying 'arch'. |
| 33 |
|
| 34 |
This is nonsense. There are some packages that are keyworded arch for a |
| 35 |
reason. i.e. they are different than those keyworded ~arch. If you are |
| 36 |
saying that there is no difference, maybe you should do some homework. I |
| 37 |
really don't think the semantic problems here are worth pursuing. If there |
| 38 |
is a problem with calling certain ebuilds "stable", that is because there |
| 39 |
are bugs. So what? At least once a month I find a new bug in 10.3.9, which |
| 40 |
I installed when it was released. |
| 41 |
|
| 42 |
> >Can someone explain what is to be gained from this that cannot be |
| 43 |
> >achieved with automated builds (e.g. to weed out the badly broken |
| 44 |
> >stable packages and check the deps of the ~ppc-macos packages); as well |
| 45 |
> >as a policy to relax the "30 day" rule? |
| 46 |
> |
| 47 |
> What automated builds? AFAIK, we don't have an automated build system, |
| 48 |
> and one won't exist for a Real Long Time(tm). Once it does, I'm all for |
| 49 |
> keeping a stable branch. Until then, I find that keeping a stable branch |
| 50 |
> is way more work than we can keep up with, for all the reasons cited in |
| 51 |
> my previous message(s) to this list. |
| 52 |
|
| 53 |
And I explained how to avoid pressure to "keep up", in my previous |
| 54 |
messages. As yet, no one has responded the questions and concerns raised |
| 55 |
there-in. |
| 56 |
|
| 57 |
In as much as you and Lina have explained the rationale for such a |
| 58 |
retrograde step, that rationale permits better alternatives. Either that |
| 59 |
is because you haven't published your rationale completely, or it is |
| 60 |
because your proposal is inferior. |
| 61 |
|
| 62 |
I understand your predicament, I'm just trying to avoid what I see is an |
| 63 |
over-rereaction to it. Hence the debate. |
| 64 |
|
| 65 |
> I don't mean to sound rude, here; I apologize in advance if I do. Please |
| 66 |
> don't take any of this personally. |
| 67 |
|
| 68 |
No offence taken. |
| 69 |
|
| 70 |
-f |
| 71 |
-- |
| 72 |
gentoo-osx@g.o mailing list |
Archives