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
In Reply to: Re: [gentoo-osx] on stable and unstable ppc-macos by Lina Pezzella
On Sun, 4 Sep 2005, Lina Pezzella wrote
> > On Sep 4, 2005, at 10:01 PM, Finn Thain wrote: > > > >Uh, no? The x11-libs/qt deps are indeed correct. Please do your > > >homework before posting to this list; you should read up on Gentoo > > >policy about DEPENDS and packages that are in 'system', such as > > >baselayout. > > > > > > >If that is the case, shouldn't qt be hard masked? If you move > >everything from arch to ~arch, you will be doing a lot more of that. > > I don't think you understand the difference between arch and ~arch, nor > the use of package.mask. QT is marked ~arch for several reasons 1) it > compiles and works on multiple unstable systems, 2) it has not been > tested against a stable environment and has not been bug-free for 30 > days, thus it cannot be "arch". If you wish to try to use a ~arch > package on an arch system, that's fine. Just don't yell when it breaks.
Yep, that's pretty much how I understand the difference between arch and ~arch. There is no disagreement here, but you missed my point: which is what happens (under your ~arch proposal) when a hypothetical ~arch qt-x.y.z breaks because I'm running a ~arch baselayout (but not the same ~arch one used when the dev keyworded qt-x.y.z with ~arch)? What happens is this: qt breaks, i.e. similar bug report to what we have now _unless_ that qt gets hard masked. Abandoning arch deprives you of a useful feature of portage. No-one has indicated how that functionality might be recovered in the future.
> > > > >Should Gentoo policy change, I would have absolutely no problem (and > > >would actually encourage) adding 'virtual/baselayout' to DEPENDS > > >where necessary. Brian Harring has also discussed this on gentoo-dev, > > >in relation to 'BDEPENDS'. > > > > > > > > > >Well, moving stable packages to testing also creates a misnomer. > > > > > > > > > >Again, do your homework. Stable packages are a subset of testing > > >packages for any given arch. By specifying '~arch' in your KEYWORDS > > >(in /etc/make.conf), you are actually implicitly specifying 'arch'. > > > > > > >This is nonsense. There are some packages that are keyworded arch for a > >reason. i.e. they are different than those keyworded ~arch. > > Actually, they're not different. The packages are exactly the same. > "arch" designates that the package has been sufficiently tested and > bug-free for long enough to be considered "stable".
This is a contradiction in terms. You say, they're not different, yet one can be considered stable and one cannot? Again, you've missed my point (which was purely a response to your complaint about a misnomer, i.e. a semantic issue that really is inconsequential).
> >If you are saying that there is no difference, maybe you should do some > >homework. > > ... > > >I really don't think the semantic problems here are worth pursuing. If > >there is a problem with calling certain ebuilds "stable", that is > >because there are bugs. So what? At least once a month I find a new bug > >in 10.3.9, which I installed when it was released. > > Then in my understanding of proper QA, 10.3.9 should not be "stable" > either. Seriously though, we have a lot more bugs.
I do take Mac OS X bugs seriously. FWIW, the most recent one I found was an nasty ipfw bug that will never be fixed.
> I am not comfortable saying something is stable when it is clearly > buggy.
There is no such thing as bug free. There is only "free of known bugs". Now, if you relax the 30-day rule, you just change the definition of "stable" slightly so that it becomes achievable within the limited resources of the project. "Stable" was never anything more than a line in the sand. It might be useful to look at ways minor-architectures (say m68k, s390 or BSD) cope with the limited resources problem.
> > > >Can someone explain what is to be gained from this that cannot be > > > >achieved with automated builds (e.g. to weed out the badly broken > > > >stable packages and check the deps of the ~ppc-macos packages); as > > > >well as a policy to relax the "30 day" rule? > > > > > > > > > >What automated builds? AFAIK, we don't have an automated build > > >system, and one won't exist for a Real Long Time(tm). Once it does, > > >I'm all for keeping a stable branch. Until then, I find that keeping > > >a stable branch is way more work than we can keep up with, for all > > >the reasons cited in my previous message(s) to this list. > > > > > > >And I explained how to avoid pressure to "keep up", in my previous > >messages. As yet, no one has responded the questions and concerns > >raised there-in. > > Sure, an automated system is a great idea. The problem is that it > requires a lot of work to build one. It is in the works for now, but > it's not here yet, so until then we have to deal with what we've got. > Once we have an automated system and our setup isn't as dynamic, we can > easily add support for a stable configuration.
Automated builds address the QA problem. It is a completely seperate issue which I probably shouldn't have raised in the context of the s/ppc-macos/~ppc-macos/ proposal, simply because that proposal has nothing to do with improving QA. -f
> - --Lina Pezzella > Ebuild & Porting Co-Lead Gentoo for OS X
-- gentoo-osx@g.o mailing list