Re: [gentoo-dev] Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

On Thu, 20 Dec 2007 00:07:35 +0000
Steve Long <slong@××××××××××××××××××.uk> wrote:
> > Except people *do* have generated DESCRIPTION etc, and with good
> > reason. A simple example is the vim-spell-* packages.
> >
> OK. Do you think a generated EAPI is a good idea? I'm curious as to
> how that would be reflected in the filename (as well as your reasons
> ofc.)

I'm suggesting that if EAPI is a variable, there are use cases for being
able to set the variable in ways other than right at the top of the
ebuild. If it isn't a variable then those use cases aren't relevant.

> No: without knowing the EAPI when generating said data. If that needs
> to be known relatively soon in order to generate the rest, extract it
> early. You still only need to load the file from disk once, and you
> don't need to source to get that data, given one simple restriction
> (only declaring it once.)

You can't get the EAPI from the ebuild without knowing what EAPI the
ebuild uses. That's one of the points you're missing.

> >> (I note this is a technical consideration of the implementation,
> >> given as a reason to change a clean API-- with consequences for
> >> workflow.)
> >
> > No no. It's already an ebuild-visible issue, and there's no way it
> > can't be that doesn't involve imposing restrictions upon every
> > single possible future EAPI.
> >
> The *reason* for the change is about the implementation, and it is not
> necessary.

It's an ebuild issue, not a package manager issue.

> I accept it would make metadata generation quicker, but the
> end-user can already use -metadata-transfer atm and never need to run
> that process. It would save many more cycles if more users did imo

You're confusing the two different types of metadata. Which again shows
that you need to start understanding the metadata process before trying
to discuss design decisions relating to it...

> (optimising early here seems silly tbh, given that paludis now
> requires ruby.)

Eh? Now what're you on about?

> Given that, as a user I see no benefit to my machines that would
> justify the maintenance headache which I know as a coder this will
> result in.

There is no maintenance headache.

> Quite apart from all the changes to supporting tools and workflow,
> it's pushing an implementation-specific datum into a namespace where
> it's neither needed nor useful, apart from to the implementation.

It's an ebuild issue, not a package manager issue.

> >> > Ebuilds are not config files.
> >> >
> >> Indeed not, but they can be parsed as such for simple, core,
> >> metadata.
> >
> > There is currently no information available from an ebuild that can
> > be parsed by any tool other than bash.
> >
> OK, but restricting EAPI= across the board (in the way that others
> have already asked for) and enforcing it via repoman would mean EAPI
> could easily be extracted.

Except that it's an arbitrary, pointless restriction.

> > And again, you show that you don't understand what's going on. EAPI
> > is only specified once except where developers screw up. The GLEP
> > merely moves the EAPI to being set *before* the metadata is
> > generated, which removes all the restrictions that having EAPI as
> > part of the ebuild's content imposes.
> >
> Hmm I think you should consider the example that this sub-thread is
> about, and whether an apology would be in order.

Huh?

> Since only declaring it the once /seems/ ok with you, what on Earth
> is so hard about extracting it?

With the current situation, the EAPI has to be known for the EAPI to be
calculated. Adding in a pre-pass layer enforcing new file format
restrictions does not solve the problem we're trying to address.

> I'm sure ruby has sufficient text processing capability if the C++ is
> a bit much for you; I remember there was that long-term bug in
> paludis not being able to deal with whitespace in config files, so
> clearly something's up with your text-processing. Hope that's finally
> fixed now.

Again, huh?

-- 
Ciaran McCreesh