[EMAIL PROTECTED] wrote:
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.
find /usr/portage -name *ebuild
find /usr/portage -name *ebuild*
That doesn't seem that much harder to me... Same for the file detection
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).
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.
Still, the GLEP addresses the very point of what logic has to be
followed if the EAPI exists in the filename, in the file, or both. It
talks of pre-source EAPIs and post-source EAPIs. Complicated.
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
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.
That wasn't the point I was trying to make. I am not saying that the
extension has special meaning (even the . has no meaning, really, in
unix) to software. I mean that people associate certain types of files
with certain extensions. I'm speaking more of the human interface here.
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
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. 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
Also, sourcing a package to extract one metadata key takes much more time
than just not loading it in the first place.
I understand there are technical/performance issues to solve, but this
does not, IMHO, justify moving this info into a filename/extension.
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.
But when they do need the new features, they need to use the new EAPIs.
This is not a matter of degree - it is a matter of defining the