| 1 |
On Sat, 3 Sep 2005, Lina Pezzella wrote: |
| 2 |
|
| 3 |
> >The problem is happening for real at |
| 4 |
> >http://bugs.gentoo.org/show_bug.cgi?id=87758 |
| 5 |
> > |
| 6 |
> >there baselayout is necessary. However, baselayout is only pulled in |
| 7 |
> >the initial "emerge system" if you use ACCEPT_KEYWORD="~ppc-macos". |
| 8 |
> >Hence, I can't compile, because QTDIR is not set for me, while someone |
| 9 |
> >having a complete ~ppc-macos system can. Portage won't pull the |
| 10 |
> >dependency of baselayout for a reason I think, but the particular |
| 11 |
> >problem sheds this light on the whole problem of how to test what on |
| 12 |
> >which system. |
| 13 |
> |
| 14 |
> This is basically the basis of Hasan and my proposal to drop stable |
| 15 |
> support for ppc-macos. The reason "emerge system" pulls in different |
| 16 |
> packages dependent on whether you are running ~ppc-macos or ppc-macos is |
| 17 |
> that baselayout-darwin and coreutils-darwin are not yet ready for |
| 18 |
> stable. What I mean by this is that they haven't been sufficiently |
| 19 |
> tested and may still change significantly. |
| 20 |
|
| 21 |
Are there known bugs with the ~ppc-macos baselayout? |
| 22 |
|
| 23 |
> The crux of the issue here is that we are only really pretending to have |
| 24 |
> stable support. We all agree that there are "stable" packages that don't |
| 25 |
> work. This is not "stable", and imho we shouldn't pretend to have stable |
| 26 |
> support when we really don't. Additionally, I think QA would improve |
| 27 |
> drastically if all developers could work on the same system setup and |
| 28 |
> expect users to have the same system setup. |
| 29 |
|
| 30 |
Yes, and if devs used stable, that would improve QA also. If the dev that |
| 31 |
keyworded qt was using stable, s/he would have found that the qt deps were |
| 32 |
wrong because they don't include the baselayout requirement. |
| 33 |
|
| 34 |
> Once we have the manpower and a less dynamic setup (right now our |
| 35 |
> profiles change frequently, we are toying with the prefixed-install |
| 36 |
> idea, baselayout and coreutils are changing) we definitely should |
| 37 |
> support stable. Until then I think it is just a misnomer that should be |
| 38 |
> dropped. |
| 39 |
|
| 40 |
Well, moving stable packages to testing also creates a misnomer. |
| 41 |
|
| 42 |
> > |
| 43 |
> >I still think that I either shouldn't have been able to emerge QT or |
| 44 |
> >that "emerge system" should provide the same base for {,~}ppc-macos, |
| 45 |
> >since portage doesn't pull these packages because they are never |
| 46 |
> >depended on. |
| 47 |
> |
| 48 |
> If we only had ~ppc-macos, this would have never happened, nor would the |
| 49 |
> bug on mediawiki. |
| 50 |
|
| 51 |
If you had accurate QT deps, this would never have happened either. If |
| 52 |
everyone used testing, that dep problem would never have been found. That |
| 53 |
isn't an improvement in QA. |
| 54 |
|
| 55 |
Can someone explain what is to be gained from this that cannot be achieved |
| 56 |
with automated builds (e.g. to weed out the badly broken stable packages |
| 57 |
and check the deps of the ~ppc-macos packages); as well as a policy to |
| 58 |
relax the "30 day" rule? |
| 59 |
|
| 60 |
-f |
| 61 |
-- |
| 62 |
gentoo-osx@g.o mailing list |
Archives