On Mon, 5 Sep 2005, Grobian wrote:
> I was/am one of the people to have the misconception that ~arch means > the ebuild is fine (why else do I test it for in any possible situation) > but the software may be buggy. > > The only difference between ~arch and arch is that the ebuild might > suck! I agree. Maybe you could add that ~arch means "ebuild is fine for at least one combination of USE flags for at least one profile"? What's more, an ebuild that doesn't suck in only one profile can still go stable if it gets package.masked in the others. (Comments in package.mask indicate that this is current practice.) > Now it suddenly makes sense that such ebuild is being stabled after 30 > days, because the assumption is there that the software being installed > itself is stable, as upstream called it stable. > > Now I don't think this particular quote should be taken as 'the law', > but it nicely shows that even on the base of Gentoo, the correct > interpretation for ~arch and arch is not really known. Nathan said, "-arch :: the end-user software is/might be flakey", but this doesn't say anything about the ebuild. I'd like to know where the package maintainer comes into it. If the package maintainers are keeping on top of the porting going on upstream, they will know when an OS X bug is fixed. If they are assigned the bug, and they release the fix, do they change the keyword from -arch to ~arch? nano is a good example. It was masked in default-darwin/package.mask, but could have been a -arch keyword. Once upstream fixed the bug, the bugzilla entries fell to the macos devs because the profile was masking the fix. If the package maintainer had marked the fix ~arch, users could have emerged it without sending new bug reports... -f -- [email protected] mailing list
