Re: [gentoo-dev] A few questions to our nominees

On Mon, 9 Jun 2008, Joe Peterson wrote:

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

Okay... so:
   find /usr/portage -name *ebuild

becomes:
   find /usr/portage -name *ebuild*

That doesn't seem that much harder to me... Same for the file detection 
for editors.

> 2) Having the same info in more than one place is generally a bad idea in
>   any design - this is true in any discipline. [...]

If you read the proposal more closely, you would notice that it 
specifically says to *not* specify EAPI in more than one place. It belongs 
solely in the filename suffix. The only reason the EAPI variable would be 
recognized inside the file itself is to allow for backwards compatibility 
with the current way EAPI=1 is done -- this behavior would be discouraged 
in all future ebuilds.

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

In most unixes, the file extension is completely meaningless. What matters 
is the contents of the file. Nautilus, etc, mostly use detection based 
upon the files contents to identify file types (at least for local files), 
not file extensoins.

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

The reason for this is that, while the current two EAPIs don't cause 
trouble if you try to source them when you don't support them, that 
doesn't mean future ones won't. I'm not talking about anything silly like 
rewriting ebuilds in python, but things like changing syntax for DEPEND 
could potentially confuse older package managers. By adding the EAPI 
specification to the filename instead, old package managers just plain 
won't see packages they don't understand, so there's no need to worry 
about this.

Also, sourcing a package to extract one metadata key takes much more time 
than just not loading it in the first place.

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

New eapis aren't necessarily of any immediate use to people. Those who 
don't see the need for them can continue to just use EAPI=0, plain old 
.ebuild files of the sort that've been around for years, and for many 
packages this is totally appropriate. The only devs who should care are 
the ones who have a need for the new features.

Users shouldn't ever have to read the ebuild files themselves. The package 
manager should tell them everything they need to know.

> 2) It is not an elegant filename policy.  Many systems have elegance as
>   a design goal.

That's a matter of opinion. It seems perfectly elegant to me -- not to 
mention the various, rather clear technical benefits of it.

> 3) Assuming going this route is a mistake, it could be hard to reverse.

Not really. The entire point of this scheme is that we can change at any 
time w/o breaking stuff. If we decide to go with .pbuild files for the 
future, we can just do that. Old package managers still won't care.

-- 
Mike Kelly
-- 
gentoo-dev@l.g.o mailing list