pioto@pioto.org 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.
>
> 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.
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"
>> (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.
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
> about this.
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
like ".eb".
> 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
filename format. Once you allow freeform ".ebuild-????" extensions,
everyone has to deal with the possibility of their existence.
> Users shouldn't ever have to read the ebuild files themselves. The package
> manager should tell them everything they need to know.
It doesn't matter, users still will look at the builds and the
directories they are in. And I am sure many users do this regularly.
We are not hiding the details of the files and filenames in an opaque
database where none of this would matter (we're not MicroSoft, after all
:). What Gentoo proudly calls the main portage tree is out there for
all to see and examine, which is a good thing.
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.
Everything else in the filename is something portage exposes to them in
its interface (category, package, version, revision, etc.), so this
would be the first thing in the filename that would *not* match up with
something we want to expose to users. EAPI is really something that
should be under the hood.
>> 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.
Yes, it is a matter of opinion, and I feel GLEP 55 would do things in a
very non-standard and confusing way, for users and for devs.
The fact that it makes the technical solution particularly easy (or an
easy short-cut) is not a justification.
>> 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.
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.
For example,
http://en.wikipedia.org/wiki/Alphabetical_list_of_file_extensions#E does
not list ".eb", so gentoo could adopt that one, slowly phasing out
".ebuild" over time. At least this would signify that it is an ".eb"
(ebuild) file, not that it is an ".ebuild-4", which happens to be a type
of ebuild file that requires version 4 of EAPI.
-Joe
--
gentoo-dev@lists.gentoo.org mailing list
>> 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.
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"
>> (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.
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
> about this.
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
like ".eb".
> 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
filename format. Once you allow freeform ".ebuild-????" extensions,
everyone has to deal with the possibility of their existence.
> Users shouldn't ever have to read the ebuild files themselves. The package
> manager should tell them everything they need to know.
It doesn't matter, users still will look at the builds and the
directories they are in. And I am sure many users do this regularly.
We are not hiding the details of the files and filenames in an opaque
database where none of this would matter (we're not MicroSoft, after all
:). What Gentoo proudly calls the main portage tree is out there for
all to see and examine, which is a good thing.
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.
Everything else in the filename is something portage exposes to them in
its interface (category, package, version, revision, etc.), so this
would be the first thing in the filename that would *not* match up with
something we want to expose to users. EAPI is really something that
should be under the hood.
>> 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.
Yes, it is a matter of opinion, and I feel GLEP 55 would do things in a
very non-standard and confusing way, for users and for devs.
The fact that it makes the technical solution particularly easy (or an
easy short-cut) is not a justification.
>> 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.
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.
For example,
http://en.wikipedia.org/wiki/Alphabetical_list_of_file_extensions#E does
not list ".eb", so gentoo could adopt that one, slowly phasing out
".ebuild" over time. At least this would signify that it is an ".eb"
(ebuild) file, not that it is an ".ebuild-4", which happens to be a type
of ebuild file that requires version 4 of EAPI.
-Joe
--
gentoo-dev@lists.gentoo.org mailing list
