Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

[Jim Ramsay]

Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:
> On Tue, 24 Feb 2009 12:25:27 -0500
> Jim Ramsay <lack@g.o> wrote:
> > > ...and it means we can't change name or version rules.
> > >
> > > ...and it means over doubling the best possible time to work out a
> > > dependency tree in the common case where the metadata cache is
> > > valid.
> > >
> > > ...and it means we can't make arbitrary format changes.
> >
> > Those would all land in the category of "backwards compatibility"
> > mentioned below, as they would all break current sourcing rules.
>
> No, they're also future issues. Without glep 55, every time they come
> up we have to go through the whole mess again.

This minor/major EAPI scheme is exactly equivalent to glep 55 in
the ways that it addresses the non-implementation-specific
details - It could even be added as a caveat to glep-55 that says
something like:

"You should not change filename extension (ie, major-EAPI version, or
EPARSE version, or whatever we want to call it...) except when you *have
to* because of changes such as name or version rules, arbitrary format
changes, or anything else that breaks the sourcing rules of the
existing filename extensions. Simpler feature improvements can be done
using whatever internal minor-EAPI version is defined by the major-EAPI
version."

This doesn't prevent you from changing the filename extension when you
have to do so, it just suggests that maybe you don't have to do it for
every single feature-set you may want to implement.

> > > Developers already have to stop and think and consult the
> > > conveniently available table of features for EAPIs. By splitting
> > > the EAPI concept in two you're doubling the amount of data to be
> > > learnt.
> >
> > I would think that this is a very small cost, and the benefit would
> > be (I hope) that more people would agree on the solution and then
> > we can go forward. Is that not a valid consideration?
>
> I'd expect to see changes that would warrant a major bump in every
> other EAPI or so anyway, so it's not really worth the complexity.

If that is indeed the case, then adding this caveat to glep-55 is
basically a nop.  If every EAPI includes a non-backwards-compatible
change that breaks existing PMs, the filename extension will be changed
every time.

But when you say "worth the complexity", I'm not exactly sure what
your standards of "worthiness" are.

I don't think the human cognition of a 2-level versioning scheme is
that tricky, so I assume you must mean complexity in the internals of
package managers - but this should just be a Simple Matter Of
Programming.

I'll further qualify this response by mentioning that I am not a package
manager maintainer.  I don't know beans about metadata and cacheing and
what the tradeoffs may be between a two-level EAPI and a single-level
EAPI stored in the filename.  I understand that parsing two-level EAPI
is "more expensive" than a single-level stored in the filename.  I don't
however know how to figure out if it is "too expensive", or whose
subjective scale we should use to measure this.

I personally feel the "complexity" that you say is too costly is a fair
tradeoff for a proposal that people will accept.

(Of course I have no idea if people actually would accept a two-level
EAPI any more than glep-55 as-is... I just think it addresses the
concerns I've heard in this thread in a way that does not break
the valid solutions to real problems presented in glep-55)

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)