Ciaran McCreesh wrote:
> On Mon, 09 Jun 2008 19:49:08 -0600
> Joe Peterson <lavajoe@g.o> wrote:
>> I'm not saying it's a lot harder.  But it is more complex and less
>> elegant.  Also, it is error-prone.  If someone, by habit, looks for
>> all "*.ebuild", he will miss a portion of the ebuilds and not even
>> realize it at first (or ever).
> 
> Yes, if something changes, and people carry on doing the old thing by
> habit, then things go wrong.

Yes, if everyone is perfect and remembers to do things perfectly right,
there would never be issues in many things, but when you make something
more complicated, there will be more errors.

>> 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.

>> 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.

>> 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.

>> Along those lines, as I've said before, migrating to a new extension,
>> *one-time*, as a solution to this, although not optimal, would be far
>> more satisfactory than introducing a series of ever-changing
>> extensions.
> 
> No it won't. It means future EAPIs will be restricted to some
> particular source format.

I assume you mean that EAPI needs to be in the file - again, is this
bad?  Many file formats specify a file format version as part of the file.

						-Joe

-- 
gentoo-dev@g.o mailing list