Ciaran McCreesh wrote:
>> > 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.
>>
I don't think it's that hard to understand "You can only set EAPI *once* in
your ebuild." Are you really saying devs won't get that?
Who are these mythical "people"? Devs take a quiz: the EAPI setting
restrictions can easily be added to it, as well as being documented
elsewhere.
That would of course have to be done doubly so for your GLEP, which imposes
a much more bizarre restriction: that the EAPI must go in the filename.
>> 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).
>
Odd: I found repoman very fussy about those. Leaving the digs at portage
aside, that's what the new commit reviews are about.
>> > 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"
>
Wow, yet another contrived b0rkage. You really don't have a very high
opinion of Gentoo devs, do you?
> EAPI="1"
> export EAPI=2
>
> src_compile() {
> cat <<END > somefile
> EAPI=3
> END
> }
>
All those would be dealt with by the well-defined syntax. I'd start with:
EAPI="foo" on its own on a line. The first setting is taken.
>> > 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...
>
Somehow I'm not reading "Brian and I agreed that.." and it concerns me that
we haven't so far had portage and pkgcore devs chiming in that your GLEP is
just what they want as the solution to several issues, meriting the work
required to change over, and the future hackiness and restrictions it
imposes.
>> 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 sounds like a borked package manager, and something which should not be
allowed per the spec. If an ebuild author sets EAPI that's what the
metadata EAPI must reflect.
> 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.
>
Or you're just contriving examples.
> (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.
It's up to the eclass/ebuild author to deal with the consequences of code
they write. In the same light, it's up to the PM devs to ensure that the
EAPIs they support work correctly.
> 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.)
>
If you could come up with a more cogent example (that actually poses a
technical challenge) perhaps your peers can help you with the difficulties
you are having. That's what a dev mailing list is for.
--
[EMAIL PROTECTED] mailing list
