Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Wednesday 17 May 2006 23:55, Ciaran McCreesh wrote: On Wed, 17 May 2006 17:38:45 -0400 Mark Loeser [EMAIL PROTECTED] wrote: | 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. Several arch teams have already stated their intention to go ahead with a Paludis profile, be it top level (ideal) or as a subprofile of their own individual profiles. Is there any technical reason that the QA lead wants to override the arch teams' wishes? Adding profiles is technically broken. This is a QA violation, so very much a QA lead problem. Further it creates a split in the gentoo organization. That makes it a metastructure, i.e. ME, problem. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpGFJIWDvFxI.pgp Description: PGP signature
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thu, 18 May 2006 12:49:29 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: Adding profiles is technically broken. How? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
Request for a decision acknowledged. Fwding on mail to the rest of the council to ensure they see it. On Wed, 2006-05-17 at 17:38 -0400, Mark Loeser wrote: 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, -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thu, 18 May 2006 15:34:28 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: Requiring duplication of profiles for every package manager. It requires duplicating nothing. This is exactly why we have cascading profiles. Profiles determine what defaults are, and on some level what is installed. What useflags are supported, and some other things. Profiles do not determine how something is installed. A package manager determines how things are installed. As such any profile should work with the package manager. And any profile does work with the package manager. What I want to change in the profile is exactly what is installed by default, which is as you say precisely what profiles are for. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thursday 18 May 2006 16:03, Stephen Bennett wrote: On Thu, 18 May 2006 15:34:28 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: Requiring duplication of profiles for every package manager. It requires duplicating nothing. This is exactly why we have cascading profiles. Cascading profiles form a tree with N nodes. Some of these nodes are abstract in the sense that they are not directly usable. Say that leaves M possible profiles. To have paludis be on par with portage, each of these M profiles would have a leaf added for paludis. The same holds for pkgcore and for any other package manager. This would mean that we have N+2M profiles. With a paludis and pkgcore toplevel profile this would even be worse and amount to approximately 3N profiles. In the leaf version, all M paludis specific profiles are equal. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpp4sTC7jM04.pgp Description: PGP signature
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thu, 18 May 2006 16:37:00 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: Cascading profiles form a tree with N nodes. Some of these nodes are abstract in the sense that they are not directly usable. Say that leaves M possible profiles. To have paludis be on par with portage, each of these M profiles would have a leaf added for paludis. The same holds for pkgcore and for any other package manager. This would mean that we have N+2M profiles. With a paludis and pkgcore toplevel profile this would even be worse and amount to approximately 3N profiles. In the leaf version, all M paludis specific profiles are equal. OK, a valid technical objection. The way to avoid this, as I see it, is to remove all direct references to Portage and its dependencies (Python?) from the system set, and replace them with the virtual. Then make sure that no package assumes that Python will be in system, and explicitly depends on it where necessary. At that point, a system could sanely be installed with any package manager by installing it before the rest of the system set. Long term this is possibly a better solution, but in the short term it requires an order of magnitude more effort, and has a significant effect on every profile in the tree. My original intention was to avoid having to change anything for other developers or people who still want to use Portage. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thu, 2006-05-18 at 16:37 +0200, Paul de Vrieze wrote: On Thursday 18 May 2006 16:03, Stephen Bennett wrote: On Thu, 18 May 2006 15:34:28 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: Requiring duplication of profiles for every package manager. It requires duplicating nothing. This is exactly why we have cascading profiles. Cascading profiles form a tree with N nodes. Some of these nodes are abstract in the sense that they are not directly usable. Say that leaves M possible profiles. To have paludis be on par with portage, each of these M profiles would have a leaf added for paludis. The same holds for pkgcore and for any other package manager. This would mean that we have N+2M profiles. With a paludis and pkgcore toplevel profile this would even be worse and amount to approximately 3N profiles. In the leaf version, all M paludis specific profiles are equal. But Paludis supports multiple inheritance. Would it be feasible to have Paludis users create /etc/make.profile as a directory, with /etc/make.profile/parent inheriting from both their chosen gentoo-x86 profile and a profile in the paludis tree? (I guess this looks like offering a technical solution to a political problem... sorry about that.) Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thu, 18 May 2006 17:19:26 +0100 Edward Catmur [EMAIL PROTECTED] wrote: But Paludis supports multiple inheritance. Would it be feasible to have Paludis users create /etc/make.profile as a directory, with /etc/make.profile/parent inheriting from both their chosen gentoo-x86 profile and a profile in the paludis tree? Certainly possible, and even possible without doing anything ugly if we extend the inheritance to allow for paths specified relative to a named repository. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
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
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Wed, 17 May 2006 17:38:45 -0400 Mark Loeser [EMAIL PROTECTED] wrote: | 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. Several arch teams have already stated their intention to go ahead with a Paludis profile, be it top level (ideal) or as a subprofile of their own individual profiles. Is there any technical reason that the QA lead wants to override the arch teams' wishes? -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Wed, May 17, 2006 at 05:38:45PM -0400, Mark Loeser wrote: 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. Hear, hear. It should be clear to everybody by now that the thread in question is not going to lead to a solution. I hereby second the request set forth by Mark. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgp4jtXYmhF7C.pgp Description: PGP signature
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
Henrik Brix Andersen wrote: [Wed May 17 2006, 04:57:59PM CDT] Hear, hear. It should be clear to everybody by now that the thread in question is not going to lead to a solution. Actually, I tend to disagree with that sentiment. Sure, it's quite a long thread, but it's also covered a great deal: (a) what are the advantages and disadvantages of such a profile, (b) what such a profile would look like, (c) should an alternative package manager influence the tree before it becomes stable, (d) would bug reports for such an unstable package manager be unduly burdensome, (e) what are the invariants for an alternative package manager, (f) what would be required for an alternative package manager to become a replacement package manager, (g) is it reasonable to have an alternative, potentially replacement, package manager that is not Gentoo-owned, and I'm sure there are others. More importantly, there seem to have been reasonable answers to many of those questions. Also, it seems to me that this thread was moving towards a consensus that most people would like to see paludis mature a bit more before a profile is added, but that if there were clear evidence that paludis wasn't doing any of those things described on the paludis website then many people would, indeed, support a paludis profile in the future. (As an aside, I don't happen to agree with that presumed consensus, as I always thought that keeping the *BSD stuff in an overlay made the barrier to entry too high, and I'd hate to see that mistake repeated.) In any event, there's a common knee-jerk reaction that any lengthy thread is, by definition, a flamewar. Despite the occasionally heated rhetoric, I've seen a lot of valuable content in that thread, and that sort of discussion is certainly not something that I would want to discourage! -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpNAVhQZhJFm.pgp Description: PGP signature
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Wed, 2006-05-17 at 17:38 -0400, Mark Loeser wrote: 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. Good call Mark. I second this request. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On Thu, 2006-05-18 at 00:23 +0100, Christel Dahlskjaer wrote: On Wed, 2006-05-17 at 17:38 -0400, Mark Loeser wrote: 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. Good call Mark. I second this request. Maybe I should have ellaborated on that, I do believe that the current thread has been somewhat educational for a 'newbie' like myself, but I also think that for the future it would be beneficial for people to know how to go about similar. :) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)
On 18/05/06, Christel Dahlskjaer [EMAIL PROTECTED] wrote: On Thu, 2006-05-18 at 00:23 +0100, Christel Dahlskjaer wrote: On Wed, 2006-05-17 at 17:38 -0400, Mark Loeser wrote: 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. Good call Mark. I second this request.Maybe I should have ellaborated on that, I do believe that the current thread has been somewhat educational for a 'newbie' like myself, but Ialso think that for the future it would be beneficial for people to knowhow to go about similar. :)-- gentoo-dev@gentoo.org mailing listGlad to see my suggestion of sorting this problem before going full stream ahead: Surely then it would be better to work on a comprimise for the sake of Gentoo rather than paludis. Horse before the cart.
