[gentoo-dev] Alternative Gentoo package managers discussion request (for the council)

[gentoo-dev] Alternative Gentoo package managers discussion request (for the council)

[Mark Loeser]

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)

[Ciaran McCreesh]

On Wed, 17 May 2006 17:38:45 -0400 Mark Loeser <halcy0n@gentoo.org>
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)

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

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 <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

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
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)

[Christel Dahlskjaer]

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)

[Christel Dahlskjaer]

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)

[George Prowse]

[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]

On 18/05/06, Christel Dahlskjaer <christel@gentoo.org> 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 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
>
> Glad 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.

[-- Attachment #2: Type: text/html, Size: 3266 bytes --]

Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

On Wednesday 17 May 2006 23:55, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 17:38:45 -0400 Mark Loeser <halcy0n@gentoo.org>
>
> 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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)

[Stephen Bennett]

On Thu, 18 May 2006 12:49:29 +0200
Paul de Vrieze <pauldv@gentoo.org> 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)

[Ned Ludd]

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 <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Thursday 18 May 2006 14:16, Stephen Bennett wrote:
> On Thu, 18 May 2006 12:49:29 +0200
>
> Paul de Vrieze <pauldv@gentoo.org> wrote:
> > Adding profiles is technically broken.
>
> How?

Requiring duplication of profiles for every package manager.

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.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)

[Stephen Bennett]

On Thu, 18 May 2006 15:34:28 +0200
Paul de Vrieze <pauldv@gentoo.org> 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)

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

On Thursday 18 May 2006 16:03, Stephen Bennett wrote:
> On Thu, 18 May 2006 15:34:28 +0200
>
> Paul de Vrieze <pauldv@gentoo.org> 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: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Alternative Gentoo package managers discussion request (for the council)

[Stephen Bennett]

On Thu, 18 May 2006 16:37:00 +0200
Paul de Vrieze <pauldv@gentoo.org> 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)

[Edward Catmur]

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 <pauldv@gentoo.org> 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)

[Stephen Bennett]

On Thu, 18 May 2006 17:19:26 +0100
Edward Catmur <ed@catmur.co.uk> 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