Joe Peterson schrieb:
Ciaran McCreesh wrote:
On Mon, 09 Jun 2008 19:49:08 -0600
Joe Peterson <[EMAIL PROTECTED]> 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@lists.gentoo.org mailing list
