[gentoo-dev] Re: How not to discuss

[Steven J Long]

Duncan wrote:
> Steven J Long posted:
>
>> 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?
>
> Me?  I'm afraid you have *me* mistaken for someone else, or at least my
> position mistaken for that of someone else.
>
> I actually happen to agree with your statement of opinion as quoted
> above, now put in my own words, that an in-ebuild EAPI='blah' line (or
> similar in-ebuild equivalent, shebangs, etc), suitably restricted in
> position and value, complete with single quotes to avoid escaped-char
> issues, is sufficient.
*phew* ;)

btw repoman could easily correct this (given a valid EAPI somewhere in
the ebuild) and thus enforce it automatically while not causing the dev
any interruption in workflow (beyond a warning.)

>  Either wait a suitable time or change the ebuild
> extension *ONCE* to ensure all actively supported PMs work with this
> before the first otherwise disruptive global change (as to say filename
> version information, but that's a separate issue), and run with it.
>
The thing is we don't need to change anything beyond tightening up the
PMS. And that's been the issue: that changes to the spec are not accepted
from the list, or simply trolled on bugzilla. It's a one-way street
(hence the "broken process".)
 
> Plus the in-extension (or in-filename) solution has very similar
> restrictions. so it's not about the question of adding EAPI restrictions,
> that's a given either way.  We can just add them to the existing in-file
> solution and get on with the show, with the same ultimate extensibility
> benefits and very similar restrictions either way, so we might as /well/
> just go with simple restrictions on the current solution, and be done
> with it.
>
Agreed.
 
> But, particularly if we're going the *single* extension change route
> anyway, it's a great opportunity to do any useful cache file format
> changes, like say, a single unified metadata file for all versions of a
> package, or all in a category, or adding tags or similar metadata so for
> instance kmail can show up in both the kde-base and mail client
> categories.

I am not following why any of those require an extension change? Cache is
totally separate to ebuilds.

> The point I made, however, was entirely separate, that being that
> regardless of one's personal feelings on GLEP55 and the merits of its
> implementation, we're likely to be stuck with it, as nobody has bothered
> formulating a properly constructed alternative solution.
>
> As for whether there's even a problem, the council did vote that in
> principle, they did see the problem, and I agree, there are global format
> restrictions in the current EAPI due to the /lack/ of specifics in the
> EAPI assignment rules that ARE a problem in terms of flexibility.

So again, change the spec to reflect the reality. Problem solved. Bear in
mind that the mangler doesn't even bother looking at the version if the
EAPI is not supported.

>> 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.
>
> So you're saying the current solution, with a few minor changes, is
> enough, while I'm saying the current solution as-is, is not enough, and
> needs at least minor changes.
>
> I think we're in violent agreement there! =:^)
>
Yes but those changes are minor and simply to do with PMS. There's nothing
portage needs to change, nor are there any implications for mangler
developers (it actually makes their life easier) and ebuild authors.
 
> I'm simply adding that whatever one's position on GLEP55 and its
> suitability, given that it's remains the only formally defined proposal
> after YEARS of debate, it's likely to be the one adopted, for lack of an
> alternative.  The opposition is demonstrating by its actions that it
> simply doesn't care enough about it to be motivated to provide a
> sufficiently defined alternative, since it hasn't done so.

That's because no change is required, beyond the simple tightening of the
spec. Since no GLEP is needed, why on Earth would we bother going through
the tortuous process of arguing for one with people who insult us with every
line and add nothing else? (in 90% of the replies I get. Yes, that's a made
up stat, it could well be more.. ;)

And believe me, we get worse on bugzilla.

In a nutshell: the GLEP was rejected by consensus last year; the problem was
only ever in the PMS, nowhere else. In such a circumstance, no GLEP is
required from the "other side."

[project]
I for one am sick of all the arguing and insults (and yes, I'm aware I tend
to give as good as I get;) it's why I went off posting to this list, and to
my knowledge it's why quite a few Gentoo devs have left over the past 3
years.

Collaboration in my free time does *not* tend to go on being insulted by
people who have no clue what they are on about, in my professional opinion,
and seem to be more interested in ruining the atmosphere that this list
started out with (I recommend reading that far back to anyone who never
has. "Manners maketh the man.")

The thing is: Gentoo collaboration /could/ be so much more fun, on the list
just as much as it already is on IRC.
[/project]
--
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)