[gentoo-dev] Re: How not to discuss

[Steven J Long]

Duncan wrote:

> Thilo Bangert <bangert@g.o> posted
> 200905311126.00274.bangert@g.o, excerpted below, on  Sun, 31 May
> 2009 11:25:56 +0200:
>
>> the thing is though, nothing constructive is being said. people are
>> going in circles. ciaran and co are pushing glep55 for reasons which
>> they have stated gazillion of times and nothing new is coming about.
>>
>> other people dislike glep55 for various reasons, but they clearly fail
>> at proposing a (better) alternative (a competing GLEP).
>
>> please, please DO write a competing GLEP if you dislike GLEP55. it's
>> late, but you might just make it...
>
> And this is why GLEP55 is likely ultimately going to be approved, despite
> all the arguing.  At the end of the day, we'll need /some/ solution to
> the general problem

First we have to agree that there /is/ a problem. "Allowing -rc1 as opposed
to _rc1" is "the big one" apparently. No-one answered when I asked why an
internal format specification needs to allow this, or indeed more variants
on versions. (IME it's *better* to restrict it to one variant.)

Again, debian-style epochs (simply a numeric integer followed by : before
the usual ([0-9]+) at the start of a version) allow us this flexibility,
but as I explained before, this use-case doesn't merit it. 

They're used in Debian when upstream changes to a non-compatible (eg
overlapping) new version sequence. Whether that's needed in Gentoo, or
whether they could be used in a more interesting manner is another
discussion, which I for one would find a lot more interesting than debating
someone's unwillingness to take 'no' for an answer.

>, and the proponents of GLEP55 have troubled
> themselves to write a GLEP outlining their solution
To a non-existent problem.

> in some depth as well
> as argue for it over a period of /years/, while the opponents have...
> troubled themselves enough to argue it for years.
>
Well I'm actually a bit bemused that we are still discussing it. It's a
rank amateur solution to a non-issue, that I thought was dismissed by
consensus a year ago. A minority not accepting the majority viewpoint
doesn't change that that *is* what happened.

EAPI doesn't belong in filename the same way ACCEPT_KEYWORDS doesn't.

Or is that the next step, so that the mangler knows visibility from
filename and doesn't have to open the cache file? What next, DEPEND too?

Getting into a nonsensical debate about PN being metadata seems to be
the level of the argument, so forgive me for not being very impressed.
(It's externally derived and in fact the whole point of the product;
unless someone is proposing losing PN and PV from filename, can we
*please* dismiss that argument as the irrelevance which it is?)

> A team can have the best rhetoric in the world, but if they don't
> actually show up and field a team on game day, they lose by default.
> Fortunately or unfortunately, that looks to be where this is headed.
>
FEATURES=parse-eapi-ebuild-head shows one possible implementation.

Personally I favour restricting the EAPI='blah' line (which imo should
simply be single-quoted to avoid escaping issues, but whatever: it's easy
enough to lex in C, so I fail to see the issue lexing it anywhere else) to
before the inherit line _in_ _the_ _spec_ since no-one has given any reason
why we should want to do anything else, and afaik repoman will warn about
it anyhow.

Could *you* explain to us, why that restriction is such a bad thing?

In summary: the existing design, including harring's EAPI, suffices for all
the 'problems' raised. The most we need to do is specify that the mangler
is allowed to extract the EAPI without sourcing, the restrictions that
enable this, and that global-scope EAPI functions (including a later BASH
version) are consequently allowed.

In the meantime, while we've been discussing this for God knows how long, we
still don't have LDEPENDs, nor do we have elibs which harring envisaged
alongside eclasses and EAPI in the first place. "Broken process" afaic.

Oh btw, -scm [sic] suffix doesn't add ANYTHING to the existing cvs. prefix
that's been available in portage for at least 3 years; it's a binary datum,
either there or not. "Innovation" is not what I'd call all this.

-- 
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)