List Archive: gentoo-qa
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 Tue, 16 May 2006 19:57:13 -0400
Mark Loeser <email@example.com> wrote:
> All three are great
> ideas, but we should only support the one that is official for Gentoo,
> and not make any changes to the tree. (Note: changes here is any
> modification or addition of files in the tree for the sole purpose of
> working with an alternate package manager)
It looks to me like the best way forward is for the alternative package
managers to host their own overlays containing their profile(s) and
whatever else they want to try, until such time as they become
officially supported. I don't see that this makes things difficult for
the alternatives; the only thing they would need to do is sync the
additional overlay, which would be easy enough.
It would also encourage the alternatives to either minimise any
effects on ebuilds, or to get any desired changes to the rules
on writing ebuilds accepted into the official manager.
> Either way, I think this is something we should hold off on for now,
> and have the council decide upon.
It's unlikely we will see a sensible result from the discussion on
g-dev@, since the issue degenerates far too easily into a portage v.
others debate despite the best efforts of some. Still, you never
> We shouldn't just make these
> changes without having some discussion taking place (the flamewar on
> g-dev@ is not a discussion, and is only a small minority of people
> giving their two cents).
> Whatever the decision is, the addition of another package manager
> makes QA harder to do since we have to consider all of them. Adding
> a new package manager and saying we don't support it, nor are we sure
> if we will ever support it, does not seem acceptable at all to me.
> The decision should be made if we plan on supporting it so we can
> work on actually supporting it, or if this should be a completely
> separate project and they can work on their own to make changes to
> ebuilds which support their own functionality.
Kevin F. Quinn