Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))

[Marien Zwart]

On Thu, Feb 22, 2007 at 04:13:11AM +0000, Ciaran McCreesh wrote:
> On Thu, 22 Feb 2007 04:04:37 +0000 Steve Long
> <slong@××××××××××××××××××.uk> wrote:
> | In process terms, I can't understand why the team working on it isn't
> | a pkgcore dev (eg marienz if you can't communicate with ferringb)
>
> Because a) they haven't asked,

Since I'm a relatively active pkgcore dev and listed explicitly in the
text you reply to, I'm going to assume I'm part of the "they" here.

I have not asked for access to PMS. The whole process of "only people
we deem sufficiently skilled get access" makes me a bit uncomfortable.
For example, what if I managed to get through whatever process there
is for verifying if I'm capable of contributing, and then am unable to
actually contribute because of time constraints? I'm afraid that would
effectively reduce my "credit" for participating in future projects of
the same kind.

That's sort of a worst case scenario though. And it's likely I do lack
the knowledge and experience to contribute a lot to this
specification, but that is a bit hard for me to judge without being
able to see what is there already in the first place.

> b) they're more interested in replacing the ebuild format

I am very curious where you got that idea. No, I am not interested in
replacing the ebuild format. Nor is any other pkgcore dev as far as I
know. I do have a few ideas for extensions to the format, which work
together with the EAPI proposal.

> c) every other time they've gotten involved they've been highly
> unhelpful.

Do you have any examples in mind here? I can't think of one, I'm
curious what project you are referring to.

No longer in reply to this particular mail, but to the thread in general:

I am a bit unsure about what the goal for PMS is here. It does not
seem to be to document what a certain (the current?) version of
portage does, as the defacto standard. Instead you want to document
what portages *intention* is, or something like that. That obviously
sounds like an excellent idea, but as far as I know most of the PMS
contributors are also Paludis devs. Paludis, being an alternative to
portage, is *also* trying to handle ebuilds the way portage is
"intended" to handle them. So what I'm afraid of is that "by the time
that Paludis 1.0_pre is released" we will simultaneously see PMS
released to the public, and Paludis 1.0_pre supporting that PMS
perfectly, with all deviations on the part of portage (or pkgcore)
being considered "bugs" in their implementation of the specification.

This does not go into just how far PMS might end up deviating from
existing portage behaviour and existing ebuilds in the tree, and how
much of that is acceptable for a specification that is intended to be
picked up by the council as something official all ebuilds and
managers must adhere to. We have already seen some examples where code
used in ebuilds currently in the tree would be invalid under the new
specification. It does not seem right to me to have a specification
like this (which if it gets picked up by the council all tree ebuilds
and all package managers should comply with) written mostly by
developers of a single package manager (no pkgcore devs have access to
the PMS spec at the moment. I do not know who *does* have access
though. Is there a list somewhere, or do you need to have access to
get at the list? :) ).

Most of this could be countered by saying that there should be a
"reference package manager" to go along with the specification, but I
am not convinced this is the right approach here, since a reason to
write this specification to begin with was to be able to figure out
which of the package managers are viable portage alternatives. The
idea was to not get any messy portage quirks documented as required
standard behaviour, the risk here is that we'll now get paludis quirks
documented as required standard behaviour.

-- 
Marien.