Joe Peterson schrieb:
> Ciaran McCreesh wrote:
>> On Mon, 09 Jun 2008 19:49:08 -0600
>> Joe Peterson <lavajoe@g.o> wrote:
>>> Well, in general, if you rely on extensions changing every time a
>>> program cannot deal with a new feature of a file format, it would be
>>> quite crazy.  For example, if C programs had to start using ".c-2",
>>> ".c-3", etc., it would get ugly fast.
>> Which is why programs that use any major C feature introduced since
>> 1980 use the extension '.cc' or '.cpp'.
> 
> So why would not a one-time new extension (e.g. ".eb") do the trick,
> just like ".cc" works for C programs?  Unless you are talking about
> needing to specify the EAPI in the file if the more advanced features
> are to be used, but I see nothing wrong with that requirement - it's not
> much different than specifying a slot, keywords, whatever.
Because that is about the same "damage" (file ext. changes, people might
get confused etc.) with less capabilities.

>>> Also, it is easy to build EAPI checking into portage now, and when
>>> the requisite time passes, you only need to deal with situations
>>> where *very* old portage versions are still in use.  Since portage is
>>> typically the first thing the system upgrades after a sync, I don't
>>> see a big issue.  Or, if that is not acceptable, see my comment at
>>> the end about a one-time change to a new extension like ".eb".
>> You completely miss the point of the GLEP. We need new extensions
>> precisely because current package managers can't handle future EAPIs
>> cleanly, and we need to carry on using new extensions because otherwise
>> we restrict what future EAPIs can do.
> 
> No, I get that.  But once you develop the concept of an EAPI, the very
> next package manager version can be aware of it and check the EAPI of an
> ebuild.  If the ebuild specifies none, then it is old-style.  If it
> specifies one that is unknown or newer than what that package manager
> version knows it can handle, it can handle that case (ignore it or
> whatever).  I don't see why you need to keep bumping the
> filename/extension every time it changes from that point forward.
Because you can change the EAPI in a way that that may not work anymore.
Specifying the EAPI outside the actual ebuild is more flexible.
It doesn't have to be the file extension, but that is the obvious solution.

>>> But what users *really* don't care about is EAPIs, and this GLEP would
>>> expose that technical detail to them in a very blatent way.
>> Anyone who cares about ebuilds at a file level has to care about EAPIs.
> 
> Not really.  A typical user does not need to know about EAPIs at all,
> but he might want to peruse the portage tree to look for ebuilds.  He
> might also want to grep for KEYWORDS or whatever.  The user can delve
> into it as much as needed or desired, but if there are these mysterious
> EAPI numbers tacked onto the extensions, then it's an added complication
> that is not important to all users.
No, not really. If you have .txt, .txt-2, .text or .footext in a dir,
you would still realize, that those should be text files.
Of course, a future EAPI could be named .whatevercomestoyourmind, but
first, you can expect people to be smart enough to not do that and
second, you can still identify the packages, because they are still
named foo-version.whatevercomestoyourmind.

Bernd


-- 
gentoo-dev@g.o mailing list