Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   GLEP 55 (was: A few questions to our nominees) (http://www.linux-archive.org/gentoo-development/103691-glep-55-few-questions-our-nominees.html)

Joe Peterson 06-10-2008 01:49 AM

GLEP 55 (was: A few questions to our nominees)
 
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

Ciaran McCreesh 06-10-2008 01:58 AM

GLEP 55 (was: A few questions to our nominees)
 
On Mon, 09 Jun 2008 19:49:08 -0600
Joe Peterson <lavajoe@gentoo.org> wrote:
> 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).

Yes, if something changes, and people carry on doing the old thing by
habit, then things go wrong.

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

And if the GLEP didn't address it people would complain that it allowed
undefined behaviour.

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

Which is why programs that use any major C feature introduced since
1980 use the extension '.cc' or '.cpp'.

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

You completely miss the point of the GLEP. We need new extensions
precisely because current package managers can't handle future EAPIs
cleanly, and we need to carry on using new extensions because otherwise
we restrict what future EAPIs can do.

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

Anyone who cares about ebuilds at a file level has to care about EAPIs.

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

No it won't. It means future EAPIs will be restricted to some
particular source format.

--
Ciaran McCreesh

Robert Bridge 06-10-2008 02:36 PM

GLEP 55 (was: A few questions to our nominees)
 
On Tue, 10 Jun 2008 02:58:54 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> > 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.
>
> Which is why programs that use any major C feature introduced since
> 1980 use the extension '.cc' or '.cpp'.

Except any program using .cc or .cpp for code is liable to break on
gcc, as they are C++ file extensions, and to the best of my (admittedly
limited knowledge) C and C++ are distinct languages...

So relying on the file extension seems to be a recipe for
misunderstanding. Why limit the functionality of the package manager to
rely on the file names? How do you protect the package manager from a
malicious ebuild masquerading under the wrong EAPI? Relying on the file
name for information is the kind of design decision we laugh at in
Windows, so why adopt it here?
--
gentoo-dev@lists.gentoo.org mailing list

Ciaran McCreesh 06-10-2008 02:41 PM

GLEP 55 (was: A few questions to our nominees)
 
On Tue, 10 Jun 2008 15:36:58 +0100
Robert Bridge <robert@robbieab.com> wrote:
> So relying on the file extension seems to be a recipe for
> misunderstanding. Why limit the functionality of the package manager
> to rely on the file names? How do you protect the package manager
> from a malicious ebuild masquerading under the wrong EAPI? Relying on
> the file name for information is the kind of design decision we laugh
> at in Windows, so why adopt it here?

There is no protection against malicious ebuilds. Malicious ebuilds
already run code as root when you install them. Being able to get an
ebuild run with the wrong EAPI is utterly irrelevant.

--
Ciaran McCreesh


All times are GMT. The time now is 08:20 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.