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

[Brian Harring]

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:
> | > I'm saying that until there is an independent implementation, the
> | > specification is worthless and will contain huge numbers of errors.
> |
> | Seriously? Without an implementation, your spec of what should happen
> | will have loads of errors?
>
> Yes. It will describe what people think is allowed, rather than what
> really is.

If you're writing the spec to match what "people think", why limit the 
# of folks involved?  If you've just involved paludis devs, you're 
limiting the "what people think" to "what paludis folk think".  Not 
saying thats the case (I'd assume y'all have at least a few non 
paludis people commenting).

Regardless, my longstanding view on the matter is that eapi=0 must be 
"what it really is", ie, it should document the long term behaviour of 
portage up to the point of breaking the specification out of portage.  

Lots of folks have lots of goofy ideas about what the manager does 
(see the old gnome/metadata constant wars if in doubt), that doesn't 
mean those views are right- nor are they particularly useful if the 
intention is to document the format (wishlists should be reserved for 
revisions of the format, not documenting the existing).

Mind you, changes within limits are fine- good example is atom 
inconsistancy (bug 152127).  That said, the change there was done up 
front, rather then stating "this is how it should be".

Talking point wise, it would be good to get an idea of some of the 
"what people think is allowed, rather than what really is".


> Perfect example -- we'd never have caught the multiple
> sourcing issue without an independent implementation.

That issue was caught long ago by the portage branch of ebd (now known 
as pkgcore) actually, portage-2.1_alpha20050718 being the 
specific released version (rest where unofficial tarballs).  Tree has 
degraded a bit since then, but already went after the issue a long 
while back to try and get things cleaned.

I'm well aware thats going to be read "nya nya, we saw it first"; 
that's not the intention.  Intention is to point out that y'all are 
basically covering territory others may already have, thus potentially 
making the same mistakes others did.  Re: env save/reload mistakes, 
will address it in a seperate email within next day or so (need to 
write it mainly).


> | 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)
>
<mild reordering follows>
> b) they're more interested in replacing
> the ebuild format

Pure and absolute FUD; recall which project has added incompatible 
version extensions, which is dropping running *rm when reinstalling 
the same ver, which *still* doesn't actually implement overlay logic, 
leading to overlay authors having to copy master files into each 
overlay branch.

Not intending on bashing, point is, pkgcore has  *never* pushed 
"replacing the ebuild format", nor realistically changes to the 
ebuild/repo/configuration formats; implying otherwise is indicative of 
one being out of touch with reality.


> Because a) they haven't asked,

Oddly enough, asked.  Got the "we give access to those who are useful" 
response several time over.  Bringing up the issue, generally seems to 
trigger that response.


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

Specifics would be welcome.  I'll remind you, despite y'all coining my 
last name as verbage for 'troll', I've spent the time going over 
paludis's differing implementation pointing out the format 
incompatibilities, decent number of which y'all fixed after a bit of 
the usual warring.

Doing it formally, I hereby request access to PMS specifically with 
the intention of going over it to spot where it differs from long 
standing portage behaviour.

May view that as unhelpful to do now, but as spb and others have 
stated, can't extend the format without documenting what it is *now*.


> | a portage dev such as zmedico
>
> We have a Portage dev reviewing it.

Which, if I may ask? (vague specifics help no one).  Zmedico, 
indicated above isn't (although perhaps you're just being coy, and he 
is).  Genone isn't ever around, bit hard for him to be doing it.  
Stubbs is mia, kito/exg are both MIA afaik (additionally, prefix 
specific although both have a pretty good understanding of env 
requirements due to changing it for the prefix experiment- same goes 
for grobian despite not being an official portage monkey).

That leaves spanky, and antarus, who you specifically contradict 
within the email.

So... which?


> > and Gianelloni for the infrastructure.
>
> And what on earth do infrastructure have to do with a package manager
> specification?

Wolf31o2 (chris) is releng moreso; one of the few folks doing 
non-trivial things with the profiles pretty much, with long term 
experience doing so.

In that regard, he's one of a few handful of people who basically 
could be considered profile experts- further, he's a catalyst monkey, 
which at least currently, is the stage building method.


> Somehow I don't think you have the slightest clue what the scope of the
> document is...

The suggetions he's laying out is intended to get multiple folks 
involved who each have their own specialized domain knowledge.

For example, dismissing Chris when he's effectively the "profiles 
guy".  Granted, can involve him afterwards, but don't much see the 
point in *not* doing it up front.

Re: scope of the document; feel free to clarify the scope.


~harring