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

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk> posted
20071221135922.3781ecdd@×××××××××××××.uk, excerpted below, on  Fri, 21 Dec
2007 13:59:22 +0000:

> On Fri, 21 Dec 2007 08:43:43 -0500
> Richard Freeman <rich@××××××××××××××.net> wrote:
>> Ciaran McCreesh wrote:
>> > Please don't comment any further until you understand how this whole
>> > thing works.
>>
>> I think this is a bit of an unrealistic expectation.  This change
>> impacts EVERYBODY - devs, users, etc.

> What. It's a small change that's only visible to developers and power
> users.

But it affects all developers (and power users) in the routine way they 
do their job, dealing with ebuilds (or ebuilds plus whatever, if this 
GLEP goes thru).  As such, it's a "big" change, because it affects how a 
lot of people do their routine work.

Yes, that's quibbling over semantics and viewpoint, but it's obvious 
/some/ people consider it a big change, big enough for them to make a big 
deal about, anyway, which is what matters in terms of discussion and 
ultimate acception/rejection of the GLEP.

>> Makes a low-level detail more visible to users.
>
> Users don't see .ebuild files.

"Gentoo users", as often used in the context of this list (from my 
observation), do.  "Gentoo users" are, as used here, "Gentoo system 
sysadmins" by another name.  As such, they've always been expected to be 
at what the general IT world would consider at minimum "power user", 
certainly not the "luser" that's the general IT world's usage of "user".  
By definition, "Gentoo users" are expected to be able to RTFM, and 
expected to actually /enjoy/ the extra control of being able to mess with 
ebuild files and the like.  Otherwise, why are they using Gentoo at all, 
when it's targeted at that "power user", and there are other 
distributions out there directly targeted at the "(l)user" level?

So, "users", as used on this list, *do* see ebuild files, or at minimum, 
cannot be reasonably said *not* to see them, since many of them in fact 
do see them and make use of them, in overlays and the like.

As for the generally IT world usage of the term, (l)user, that doesn't 
come up so often here, because it's not what we deal with.  Dealing with 
them would be the job of /our/ users -- Gentoo sysadmins by another name.

>> You can't make a wild change to how EAPIs are specified - since old PMs
>> will expect it to be in the filename in a particular format.
>
> You can make entirely arbitrary changes to EAPIs with suffixes, provided
> only that you don't use either .ebuild or .ebuild-(any-existing-eapi).

OK, first, a comment on the GLEP itself:  I just looked at it again, and 
realized it doesn't actually /specify/ the name format in so many words 
or in commonly accepted syntax form.  One can see what's expected based 
on the /examples/, but it's not specified... anywhere that I could see.

So the GLEP needs something like the below (may not be technically 
correct, but as an example to be corrected as necessary when added to the 
GLEP) syntax specified:

<PF>.ebuild[-<suffix>]

IMO that's the key to beginning to clear up my (I think former) 
confusion.  Without that clearly stated, I was conflating the two 
possible changes, the one given by the GLEP, and the one left unspec-ed, 
and thus reserved for the future and/or other non-Gentoo usage, 
extensions /other/ than .ebuild[-<suffix>].

Given the conflation, I was then left confused by the GLEP requirement 
that the EAPI not be changed from that found in the filename (with the 
filename EAPI defaulting to 0 if not given), set against the argument 
that EAPI could then at some point be made dynamic, or otherwise less 
firmly specified than filename semantics requires.  Separating the 
concepts, then, clears up the confusion, since the possibility is left 
open to change to something /other/ than .ebuild[-<suffix], say fbuild, 
in the future (or for other than main Gentoo tree) as necessary, and the 
new (fbuild or whatever) format would be free to break all the current 
rules associated with .ebuild[-<suffix>] as deemed necessary.

So now I see how you could state they must remain the same (in the glep) 
yet allow for dynamically setting them ("post-source") in future non-
ebuild* formats.

Further suggestion for the GLEP, then: In addition to specifying syntax 
explicitly, note explicitly as well, that this glep deals with .ebuild* 
only, and that one possible mechanism for future incompatible changes 
would therefore be to change the extension to something other 
than .ebuild*.

This should eliminate an entire class of objections (and simple 
confusion), including my main previous one, due to the present less than 
clear specification and the confusion it caused.

(/NOW/ I see...! =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@g.o mailing list