[gentoo-qa] Support of other package managers

[gentoo-qa] Support of other package managers

[Mark Loeser]

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

This email is to gauge the opinion of everyone that is currently on the
QA team as to the matter of supporting other package managers with our tree.

As I see it, the tree is for Portage, and it is nice if it works with
other package managers (such as pkgcore or paludis), but I do not
believe we should be making changes, of any kind, just to improve how
their programs work.  I have no problems with rewrites of Portage, but
making changes to the live tree for something other than Portage does
not seem to make sense to me.  If we decide to recognize rewrites as
official alternatives, then making changes makes sense, but until that
point, I don't believe it does.

I would appreciate feedback on this so that we can come to some sort of
agreement on how situations such as this should be handled.

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-qa] Support of other package managers

[Stephen Bennett]

Mark Loeser wrote:
> As I see it, the tree is for Portage, and it is nice if it works with
> other package managers (such as pkgcore or paludis),

If anything, I see it the other way. By far our largest and most 
valuable piece of code is the tree, and Portage exists to provide an 
environment in which it can be of use.

 > but I do not
> believe we should be making changes, of any kind, just to improve how
> their programs work.  I have no problems with rewrites of Portage, but
> making changes to the live tree for something other than Portage does
> not seem to make sense to me.  If we decide to recognize rewrites as
> official alternatives, then making changes makes sense, but until that
> point, I don't believe it does.

If someone were wanting to change existing parts of the tree for no 
other reason than compatibility with another package manager, I'd agree 
with you. I don't, however, see a problem in adding a self-contained 
piece of code that has no effect on the rest of the tree.

-- 
gentoo-qa@gentoo.org mailing list

Re: [gentoo-qa] Support of other package managers

[Seemant Kulleen]

This issue is certainly a dicey one.  I don't think there is an easy to
define answer.  It has always been assumed that a portage rewrite
(whether it were a third party reimplementation in a !python language,
or pkgcore/paludis or portage-ng) would just fit right into the tree,
without making changes of any kind at all.  So I think the question that
we need to answer is *what* changes are necessary to the profiles and
*why* -- or I suppose, why would paludis/pkgcore need to have its own
profile?

I think it would be a lot easier to see what it is that needs this sort
of change before we can make an informed call about it.

thanks,

Seemant
-- 
gentoo-qa@gentoo.org mailing list

Re: [gentoo-qa] Support of other package managers

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Seemant Kulleen wrote:
> This issue is certainly a dicey one.  I don't think there is an easy to
> define answer.  It has always been assumed that a portage rewrite
> (whether it were a third party reimplementation in a !python language,
> or pkgcore/paludis or portage-ng) would just fit right into the tree,
> without making changes of any kind at all.  So I think the question that
> we need to answer is *what* changes are necessary to the profiles and
> *why* -- or I suppose, why would paludis/pkgcore need to have its own
> profile?
> 
> I think it would be a lot easier to see what it is that needs this sort
> of change before we can make an informed call about it.

Yeah, I think what's really needed is a specification of what is allowed in gentoo's official portage tree.  Let's take "per-package use.mask" (bug 96368) as an example.  It could be implemented as package.use.mask or as package.mask + use deps.  Which will it be?  Will paludis, pkgcore, and portage all handle this functionality the same way or not?  If we're going to allow new features such as this into the official portage tree, we need to make sure that they conform to a specification that everyone has agreed upon.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEak4V/ejvha5XGaMRAsiAAJ94mIvX/fbb98ng47nQ2N5TiESbfwCfRIM1
M4k5bburtTHPKzsTeWALXZU=
=q09w
-----END PGP SIGNATURE-----
-- 
gentoo-qa@gentoo.org mailing list

Re: [gentoo-qa] Support of other package managers

[Mark Loeser]

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

Zac Medico <zmedico@gentoo.org> said:
> Yeah, I think what's really needed is a specification of what is allowed in
> gentoo's official portage tree.  Let's take "per-package use.mask" (bug
> 96368) as an example.  It could be implemented as package.use.mask or as
> package.mask + use deps.  Which will it be?  Will paludis, pkgcore, and portage
> all handle this functionality the same way or not?  If we're going to allow new
> features such as this into the official portage tree, we need to make sure that
> they conform to a specification that everyone has agreed upon.

This is the exact problem I'm trying to address.  You'll never get all
of the projects to agree, since they all want to go in slightly
different directions and do different things.  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)

Either way, I think this is something we should hold off on for now, and
have the council decide upon.  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.

-- 
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-qa] Support of other package managers

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Loeser wrote:
> This is the exact problem I'm trying to address.  You'll never get all
> of the projects to agree, since they all want to go in slightly
> different directions and do different things.  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)

I don't see any reason to include support for a non-official package manager in the official gentoo repo either (given that they can host their own repository and include whatever they want).  For the sake of interoperability, I hope that the developers of these separate package managers can come together and agree on some specifications, but that's a topic for another list...

> Either way, I think this is something we should hold off on for now, and
> have the council decide upon.  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.

Yeah, it seems like this type of decision needs to be made by the council, and I hope that they decide against it.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEapB8/ejvha5XGaMRAvJOAJ9D9bkg7UoMynFNND+S8UJfLurDlwCeLeJH
EzwX3OXW21TjqytMynWfwUE=
=aGr0
-----END PGP SIGNATURE-----
-- 
gentoo-qa@gentoo.org mailing list

Re: [gentoo-qa] Support of other package managers

[Mike Frysinger]

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

On Tuesday 16 May 2006 19:57, Mark Loeser wrote:
> Whatever the decision is, the addition of another package manager makes
> QA harder to do since we have to consider all of them.

not really ... you have one official manager and QA tests with that

> 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.

why do we have to support it ?  this seems like a perfectly good application 
of EAPI that the portage peeps keep talking about

if you have a hard dcument of what it means to be compatible with EAPI=0, then 
i see no reason to block any package manager that conforms to it

whatever the latest EAPI version that the official package manager (portage is 
the current official one) supports is what the tree must conform to
-mike

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

Re: [gentoo-qa] Support of other package managers

[Kevin F. Quinn]

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

On Tue, 16 May 2006 19:57:13 -0400
Mark Loeser <halcy0n@gentoo.org> 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
know...

>  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

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

Re: [gentoo-qa] Support of other package managers

[Stephen Bennett]

On Tue, 16 May 2006 15:11:35 -0700
Zac Medico <zmedico@gentoo.org> wrote:

> Yeah, I think what's really needed is a specification of what is
> allowed in gentoo's official portage tree.  Let's take "per-package
> use.mask" (bug 96368) as an example.  It could be implemented as
> package.use.mask or as package.mask + use deps.  Which will it be?
> Will paludis, pkgcore, and portage all handle this functionality the
> same way or not?  If we're going to allow new features such as this
> into the official portage tree, we need to make sure that they
> conform to a specification that everyone has agreed upon.

Sounds sane, as long as said specification can be extended within a
reasonable timeframe. Basing this specification on what Portage
currently supports, I would add:

* Multiple profile inheritance: the `parent' file contains a list, one
per line, of profiles to inherit, as a relative path from the current
directory. Profiles are loaded in the order listed, so that later
entries override previous ones, and the current profile overrides all.
If the package manager does not support multiple inheritance, only the
first line is read (from what I'm told, this is what Portage does
currently).

* Per-package use masking: The package.use.mask file contains, one
entry per line, '<dep atom> <flags to mask>'. These flags are then
masked as normal for any package matching the atom.

* USE forcing, global and per-package: Format is the same as for use
masking, but the flags are force-enabled instead of disabled. Files are
use.force and package.use.force.

* Dep atom extensions: Basic format is the same as current Portage,
with the following additions:
 - <atom>:<slot> -- SLOT must match the value given
 - <atom>::<repository> -- the package must be taken from the
repository with the given identifier.
 - <atom>[use] -- The package must be installed with the given use flag
enabled. For <atom>[-use] the flag must be disabled. Multiple [use]
restrictions in an atom are permitted, the syntax being
<atom>[use1][-use2][use3].

The rest of our extensions are wider in scope, so that's more or less
the list of non-portage-supported features we're looking at at the
moment. Note that the new dep syntax would not be used in any ebuilds,
but only at the profile level.

If anyone wants to codify the ebuild / profile format into a formal
specification, you have my full support as long as it is easily
extensible with anything new that Portage or other package managers may
support. Obviously such extensions should be discussed beforehand, but
they should be possible within a reasonable timeframe.
-- 
gentoo-qa@gentoo.org mailing list

Re: [gentoo-qa] Support of other package managers

[Stephen Bennett]

Seemant Kulleen wrote:
> So I think the question that
> we need to answer is *what* changes are necessary to the profiles and
> *why* -- or I suppose, why would paludis/pkgcore need to have its own
> profile?

The profile currently being proposed would change the default 
virtual/portage provider, and ensure that paludis gets pulled in instead 
of Portage in the system set. It would also serve as a proving ground, 
if you will, for some profile features that Paludis supports and Portage 
does not -- for example, profile level USE forcing (for example, the 
ip28 USE flag in relevant Mips profiles), USE combination restrictions 
(see the PHP ebuilds for where this could be useful), and potentially 
multiple profile inheritance. According to my understanding of Portage's 
profile handling, these will all be silently ignored by Portage, so 
nothing will break. Paludis' profile handling is, as far as I know, 
fully backwards compatible; the new profile is purely for the change in 
the system set and to provide a place where people can use the new 
features without stepping on anyone else's toes.
-- 
gentoo-qa@gentoo.org mailing list