Ciaran McCreesh <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on Fri, 21 Dec
2007 13:59:22 +0000:
> On Fri, 21 Dec 2007 08:43:43 -0500
> Richard Freeman <[EMAIL PROTECTED]> 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
--
[EMAIL PROTECTED] mailing list
