Donnie Berkholz wrote:
> On 11:12 Sun 08 Jun     , Piotr Jaroszyński wrote:
>> looks like every nominee wants the council to be more technical so I
>> have a few technical questions for you:
>>
>> 1. GLEP54
>> 2. GLEP55
> 
> I don't have any particular objections to these, besides the vague 
> aesthetic one of having EAPI in the filename. Particularly long, weird 
> EAPIs filled with special characters (to which some will reply "So don't 
> do that").

Donnie, I agree, and I think it would be a mistake to use the filename
extension for the EAPI number, even for simple "non-long-or-funky"
EAPIs.  I know that my reasons will be considered, by some, to be
irrelevant (especially since aesthetics and/or style/elegance are of less
importance to some), but I really think this should be carefully considered;
a mistake here would be quite a shame.  I'll state again (slightly modified)
what I wrote a while back on this issue.

Technical reasons to avoid the filename:

1) Increase of [needless] complexity in filenames/extensions (and only one
   example of the impact is that searching for ebuild files becomes less
   straightforward), when things like SLOT, EAPI, etc., etc., seem to
   naturally belong as part of the script contents/syntax.
2) Having the same info in more than one place is generally a bad idea in
   any design - this is true in any discipline.  I don't care how many people
   say a) that this is not an issue or b) that it's "not a duplication",
   in every data system I've worked on, it has been a very bad idea to have
   more than one version of the same info that can get out of sync with each
   other.  Even if you take great care, I'd still always want to check both
   and not trust either version of the info blindly.  Caching or hashing is
   different (i.e. where the caching mechanism is robust), since the
   system itself keeps the cache up to date, and one version of the info
   is strictly derived from the other rather than both being the source.
3) It uses the extension in a way that goes against common use in computers,
   especially *nix.  No longer could we then say that a file of type
   "Gentoo ebuild" has the extension "ebuild"
   (simple/straightforward/standard).
4) It seems that the motivation for this GLEP is so that the tools can
   determine the EAPI without reading/sourcing the script.  In order to
   get around this, the GLEP suggests exposing this technical information
   in the filename.  This is the wrong place to expose it, and the reasons
   given are not that this detail should be exposed there but rather because
   it is inefficient to source the file to get the info.  So this is a case
   of trying to solve a technical issue by changing the interface.  I
   believe it would be more correct to attack the technical problem in a way
   that does not do this, and I am sure this can be solved.

Other reasons:

1) Littering the filename with this kind of stuff is potentially confusing to
   both devs and users - I know it's been stated that users shouldn't care,
   but I don't think that's a good reason/assumption.
2) It is not an elegant filename policy.  Many systems have elegance as
   a design goal.
3) Assuming going this route is a mistake, it could be hard to reverse.

Currently, I consider Gentoo's ebuild filename conventions simple and
elegant.  In fact, it is beautifully done.  I'd hate to see this go down the
wrong path now.

						-Joe

-- 
gentoo-dev@g.o mailing list