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@lists.gentoo.org mailing list
