List Archive: gentoo-osx
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
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
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...
email@example.com mailing list