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