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
> >If you are saying that there is no difference, maybe you should do some
> >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
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
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.
> - --Lina Pezzella
> Ebuild & Porting Co-Lead Gentoo for OS X
firstname.lastname@example.org mailing list