On Sun, 23 Dec 2007 14:54:16 +0100 Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote: > On 2007/12/23, Ciaran McCreesh <[EMAIL PROTECTED]> > wrote: > > a) It's a massive restriction on what future ebuilds can do. > > - it handles a reasonnable range of likely future EAPIs,
It doesn't, though. For example, any good solution to the current eclass
EAPI issues is likely to break it.
> - it includes the "extension changes when the way to extract EAPI
> has to change" to avoid bounding future EAPIs to this range.
Which we'll need to take anyway at some point.
> > c) It's an extremely bizarre restriction, the likes of which do not
> > currently exist, that will confuse the hell out of all the people
> > that don't realise that such a restriction exists.
>
> Devs are already used to follow numerous conventions in the way they
> format their ebuilds.
And they already arbitrarily don't follow them. We get people screwing
up whitespace and brackets in dep strings, for example (Portage doesn't
error check these very well).
> > d) It introduces a new prepass parse layer to an already complex
> > process.
>
> Both solutions add some new steps to this process, and it doesn't look
> to me like there's a significant difference beetween their respective
> added complexity. That said, you're the PM dev here, not me, so if
> you confirm that implementation of an in-contents solution is
> significantly harder, then i will accept the argument.
It's not harder (assuming the syntax is well defined -- single, double
or no quotes? export? leading whitespace? is it the first or the last
match of EAPI="" that's taken?). It's just messy, because we'd have to
deal with stupid cases like:
DESCRPTION="Config file to make Paludis support
EAPI='4' packages"
EAPI="1"
export EAPI=2
src_compile() {
cat <<END > somefile
EAPI=3
END
}
> > e) The Portage guys said no to it.
>
> When/where? I've only seen Marius commenting here, but not on that
> aspect. Also, i've read this 2005 "EBUILD_FORMAT" discussion that
> Steve Long has pointed [1], where Brian was against non-Bash parsing,
> but:
> - he was against changing files extension too,
> - the flaws in the EAPI system designed at this time is what led to
> rethinking it now.
>
> If i've missed something since then (and that's likely), could you
> give me a pointer to the archives? Thanks.
A while after that Brian and I had a huge lengthy argument on IRC about
it. I don't have IRC logs that far back, which is kind of a shame
because we covered pretty much all of the things that people are
moaning about now...
(And you'd also see the highly silly political reasons that lead to
*.ebuild* not being adopted straight off.)
> > > (until some unlikely conditions are met, like a switch away from
> > > Bash format).
> >
> > Or until we do something about eclasses and EAPIs,
>
> If you're not more specific about this "something", it's hard to say
> what solution will handle it best.
If I had a perfect solution to the eclass problem, I'd've posted it
ages ago... But it's fairly likely that a good solution will require
considerably more flexibility than a simple static value in an ebuild
file.
> My point here is that the in-contents alternative is just a syntaxic
> rule which defines a first-pass extraction of a value from an ebuild
> file (as opposed to an ebuild file name extension). How it is then
> used (what the "eapi" function does, if anything, or whether this
> value is the definitive EAPI, or how EAPI vs. eclasses is handled,
> etc.) can be subject to future changes depending on this value. That's
> part of why this solution is not more restrictive than the file name
> extension approach.
But then you get the highly weird result of setting, say, EAPI="4" in
the ebuild but the c/p-v actually having EAPI="3" because of weird hard
to see behind the scenes eclass voodoo. That's equivalent to the "using
the wrong file extension and then overriding with a variable"
situation, except that you're effectively requiring it for future
changes rather than making it something that's a big flashy warning.
(From a technical perspective, changing EAPI mid-source is a massive
pain in the ass. EAPI pretty much has to be able to tinker with PATH
and friends, and there's no sane way of modifying variables as soon as
another variable changes. For example, and not saying that this
specific case is desirable, EAPI foo could require that the first 'sed'
in PATH be GNU sed, whilst EAPI bar could require that it be the normal
system sed.)
--
Ciaran McCreesh
signature.asc
Description: PGP signature
