As the latest long thread has shown, there seems to be a split (it is hard to tell exactly) on whether or not alternative package managers, that support Gentoo ebuilds to some degree, should be added to the tree and supported. Supported in this case means having their own profiles which may or may not work with Portage. There are currently a few different Portage rewrites, or alternatives, whatever you want to call them, and all of them have their own unique features being added to them which make them incompatible with Portage. Some don't even emulate Portage's "broken" behaviour which could also cause QA problems for us if we add the package to the tree. If a package is in the tree, it is implicitly stating that we are going to offer some level of support for that application, and it increases workload for everyone that may have an ebuild that works with one package manager and not another.
Therefore, I am requesting at the next Council meeting that they discuss
and decide on how we want to handle problems like this in general. This
is not going to be the last time that someone wants to add their rewrite/
alternative of Portage to the tree. It should be decided if it is really
in the best interests of Gentoo, its users, and developers to be adding
these new managers to our own tree, instead of having them host their
altered work on their own infrastructure.
As the QA lead, I am requesting that until the Council convenes and decides
on how we should proceed, that we not add anything else to the tree
for the sole reason of supporting another package manager's features.
This includes profiles or any other packages. This will reduce
headaches for all of us, and hopefully cut down on needless arguments
that get us no where.
Thanks,
--
Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86)
email - halcy0n AT gentoo DOT org
mark AT halcy0n DOT com
web - http://dev.gentoo.org/~halcy0n/
http://www.halcy0n.com
pgpxCau7Apugg.pgp
Description: PGP signature
