[gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Piotr Jaroszyński]

[-- Attachment #1: Type: text/plain, Size: 187 bytes --]

Hello,

attaching the GLEP.

most current version:
http://dev.gentoo.org/~peper/glep-0055.html
http://dev.gentoo.org/~peper/glep-0055.txt

-- 
Best Regards,
Piotr Jaroszyński

[-- Attachment #2: glep-0055.txt --]
[-- Type: text/plain, Size: 3976 bytes --]

GLEP: 55
Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Version: $Revision: $
Last-Modified: $Date: $
Author: Piotr Jaroszyński <peper@gentoo.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 17-Dec-2007
Post-History: 17-Dec-2007

Abstract
========

This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for
example, foo-1.2.3.ebuild-1).

Motivation
==========

Including EAPI in the ebuild file extension has the following advantages:

  *  Possibility to extend the versioning rules in an EAPI, and to use them
     immediately in the Gentoo tree. For example, addition of the scm suffix -
     GLEP54 [#GLEP54]_.

  *  Possibility to extend the behaviour of inherit and add new global scope
     functions (as a result of not sourcing ebuilds with unsupported EAPI).

Specification
=============

Let's call the EAPI included in the ebuild filename the pre-source EAPI, and the
EAPI set inside the ebuild the post-source EAPI. Given these two, the final EAPI
used by the ebuild can be established by following these steps:

  *  If the pre-source EAPI is not set it defaults to 0.
  *  If the pre-source EAPI is not recognised it is returned immediately.
  *  If the post-source EAPI is not set, it defaults to the pre-source EAPI.
  *  post-source EAPI is returned.

The above process should be only used to generate the metadata cache. Should the
pre-source EAPI be unsupported the cache entry cannot be generated.

Ebuilds with unsupported EAPIs are masked.

QA tools should consider it an error for both EAPIs to be set explicitly to
different values. Package managers may warn, but must use the post-source EAPI
in such cases.

Examples:

  *  ``pkg-1.ebuild``, no EAPI set inside the ebuild
       pre-source EAPI defaults 0, post-source EAPI defaults to pre-source EAPI.
       EAPI 0 is used.

  *  ``pkg-2.ebuild-0``, no EAPI set inside the ebuild
       pre-source EAPI is 0, post-source EAPI defaults to pre-source EAPI.
       EAPI 0 is used.

  *  ``pkg-3.ebuild-1``, no EAPI set inside the ebuild
       pre-source EAPI is 1, post-source EAPI defaults to pre-source EAPI.
       EAPI 1 is used.

  *  ``pkg-4.ebuild``, ``EAPI="1"``
       pre-source EAPI defaults to 0, post-source EAPI is 1.
       EAPI 1 is used.

  *  ``pkg-4.ebuild-2``, ``EAPI="1"``
       pre-source EAPI is 2, post-source EAPI is 1.
       EAPI 1 is used, but note that one should **never** explicitly set both
       EAPIs to different values.

  *  ``pkg-5.ebuild-2``, no EAPI set inside the ebuild, package manager not supporting EAPI 2
       pre-source EAPI is 2, post-source EAPI is never checked.
       ebuild masked because of the unsupported pre-source EAPI.

  *  ``pkg-6.ebuild``, ``EAPI="2"``, package manager not supporting EAPI 2
       pre-source EAPI defaults to 0, post-source EAPI is 2.
       ebuild masked because of the unsupported post-source EAPI.

Note that it is still not permitted to have more than one ebuild with equal
category, package name, and version. Although it would have the advantage of
allowing to provide backward compatible ebuilds, it would introduce problems
too. The first is the requirement to have strict EAPI ordering, the second is
ensuring that all the ebuilds for a single category/package-version are
equivalent, i.e. installing any of them has exactly the same effect to the
system.

Backwards Compatibility
=======================

Currently ebuilds are recognised by the ``.ebuild`` file extension and hence
EAPI-suffixed ebuilds are simply ignored by the package manager allowing their
immediate usage in the Gentoo tree.


References
==========

.. [#GLEP54] GLEP 54, scm package version suffix
    (http://glep.gentoo.org/glep-0054.html)

Copyright
=========

This document has been placed in the public domain.

.. vim: set tw=80 fileencoding=utf-8 spell spelllang=en et :

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Thomas de Grenier de Latour]

On 2007/12/17, Piotr Jaroszyński <peper@gentoo.org> wrote:

> http://dev.gentoo.org/~peper/glep-0055.html

>   * Possibility to extend the versioning rules in an EAPI, and to
> use them immediately in the Gentoo tree. For example, addition of 
> the scm suffix - GLEP54 [1].
...
> Currently ebuilds are recognised by the .ebuild file extension and
> hence EAPI-suffixed ebuilds are simply ignored by the package manager
> allowing their immediate usage in the Gentoo tree.

What about other places where some "cat/pkg-version" are used? 

 - deps: ok, no pb, i guess EAPI=X ebuilds are not allowed to have
dependencies on some "cat/pkg-version" whose "version" is in a syntax
introduced in a later EAPI. Could be made explicit though.

 - metadata/cache: latest PMS i've found (2007/07/08 on dev.g.o/~spb)
says it contains some "<category>/<package>-<version>" files. If a
package manager assumes the "<version>" syntax is the one defined in
the said PMS, and you extend this syntax, don't your fear it will
trigger some bugs in said packages manager?

 - /var/db/pkg: this one is not specified anywhere afaik, but here too,
putting some "<category>/<package>-<version>" with a new "<version>"
syntax may trigger weird some packages manager bugs.  Which would
basically prevent forbid beetween several package managers which don't
support the same EAPI set, or simply downgrading your favorite one.

 - profiles/*: how will the various files there ("packages", etc.) ever
be allowed to use some atoms which use an extended versioning syntax?

I'm not saying that the idea is bad though (i 100% agree it's useful),
but "*.ebuild-x" being ignored by current pkg managers is not enough 
to conclude you can extend the versioning syntax without backward
compatibility issues.

-- 
TGL.
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

On Tue, 18 Dec 2007 00:40:05 +0100
Thomas de Grenier de Latour <degrenier@easyconnect.fr> wrote:
>  - metadata/cache: latest PMS i've found (2007/07/08 on dev.g.o/~spb)
> says it contains some "<category>/<package>-<version>" files. If a
> package manager assumes the "<version>" syntax is the one defined in
> the said PMS, and you extend this syntax, don't your fear it will
> trigger some bugs in said packages manager?

The package manager shouldn't be fishing around in metadata/cache. It
should only be doing direct lookups in there based upon ebuilds it
finds.

(latest PMS, by the way, is svn co http://svn.repogirl.net/pms)

>  - /var/db/pkg: this one is not specified anywhere afaik, but here
> too, putting some "<category>/<package>-<version>" with a new
> "<version>" syntax may trigger weird some packages manager bugs.
> Which would basically prevent forbid beetween several package
> managers which don't support the same EAPI set, or simply downgrading
> your favorite one.

You already can't downgrade package managers, so there's no regression
there.

>  - profiles/*: how will the various files there ("packages", etc.)
> ever be allowed to use some atoms which use an extended versioning
> syntax?

Currently profiles/* is limited to using EAPI-0 style things. You
can't, for example, use slot deps in profiles/. Removing this
restriction could be done in two ways (package-mask-1 etc, or
profiles/*/eapi).

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Joe Peterson]

Piotr Jaroszyński wrote:
> Hello,
> 
> attaching the GLEP.
> 
> most current version:
> http://dev.gentoo.org/~peper/glep-0055.html
> http://dev.gentoo.org/~peper/glep-0055.txt
> 
> 
> Abstract
> ========
> This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds
> (for example, foo-1.2.3.ebuild-1).

I probably missed some of the stuff leading up to this GLEP, but what is
the problem with having the EAPI in the file and determining it by
looking at the file contents?

Making the file extension variable by adding "-<EAPI>" to it would, in
my opinion, make the portage tree a bit less clean and not as elegant.
Wouldn't software (like editors determining file type by looking at what
is after the ".") also need to be reworked to recognize a variable
string after "-" at the end?

I imagine a lot of people do things now like 'find . -name "*.ebuild" |
xargs grep ...'.  Not that they could not change their habbits, but
forgetting to add a more complex matching rule could lead to errors
here.  It just seems to me that adding complexity to what is basically a
file extension is undesirable unless there is a very good reason why it
cannot be done a different way.

						-Joe
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

On Mon, 17 Dec 2007 17:10:46 -0700
Joe Peterson <lavajoe@gentoo.org> wrote:
> I probably missed some of the stuff leading up to this GLEP, but what
> is the problem with having the EAPI in the file and determining it by
> looking at the file contents?

Motivation, second bullet point:

| Possibility to extend the behaviour of inherit and add new global
| scope functions (as a result of not sourcing ebuilds with unsupported
| EAPI).

> Making the file extension variable by adding "-<EAPI>" to it would, in
> my opinion, make the portage tree a bit less clean and not as elegant.
> Wouldn't software (like editors determining file type by looking at
> what is after the ".") also need to be reworked to recognize a
> variable string after "-" at the end?

Yep, but that's not very difficult. And as a side effect, editors could
then provide EAPI aware highlighting.

> I imagine a lot of people do things now like 'find . -name "*.ebuild"
> | xargs grep ...'.  Not that they could not change their habbits, but
> forgetting to add a more complex matching rule could lead to errors
> here.

-name '*.ebuild*' isn't exactly much more complex...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Joe Peterson]

Ciaran McCreesh wrote:
>> I imagine a lot of people do things now like 'find . -name "*.ebuild"
>> | xargs grep ...'.  Not that they could not change their habbits, but
>> forgetting to add a more complex matching rule could lead to errors
>> here.
> 
> -name '*.ebuild*' isn't exactly much more complex...

No, but to be more "correct" it shouldn't be that open-ended.  For
example, it really should be a regexp that only allows a dash followed
by digits (and then nothing after).  Not hard, but if forgotten, it
could yield misleading results.  Perhaps it's more the "feel" of it that
bothers me, and once this path is taken, there is no going back.

					-Joe
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

On Mon, 17 Dec 2007 17:30:50 -0700
Joe Peterson <lavajoe@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> >> I imagine a lot of people do things now like 'find . -name
> >> "*.ebuild" | xargs grep ...'.  Not that they could not change
> >> their habbits, but forgetting to add a more complex matching rule
> >> could lead to errors here.
> > 
> > -name '*.ebuild*' isn't exactly much more complex...
> 
> No, but to be more "correct" it shouldn't be that open-ended.  For
> example, it really should be a regexp that only allows a dash followed
> by digits (and then nothing after).  Not hard, but if forgotten, it
> could yield misleading results.  Perhaps it's more the "feel" of it
> that bothers me, and once this path is taken, there is no going back.

An EAPI is not limited to a numeric name. We could call the next EAPI
"cabbage" if we wanted to. There're already various experimental EAPIs
that don't use pure numbers (for example, "paludis-1").

(Sometimes I think the next EAPI *should* be called "cabbage", if only
because it'll help disabuse people of the notion that EAPIs are
orderable...)

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Fabian Groffen]

On 18-12-2007 00:39:38 +0000, Ciaran McCreesh wrote:
> An EAPI is not limited to a numeric name. We could call the next EAPI
> "cabbage" if we wanted to. There're already various experimental EAPIs
> that don't use pure numbers (for example, "paludis-1").
> 
> (Sometimes I think the next EAPI *should* be called "cabbage", if only
> because it'll help disabuse people of the notion that EAPIs are
> orderable...)

While I feel there has been given little to no attention to what EAPI's
really are and how they relate to each other, I prefer to go this route
myself as well.  The EAPI "name" should represent the feature(s) it
adds.  However, because "features" need not to include previous ones
(why would they?), in the Prefix branch of Portage I implemented EAPI to
be a space separated list.  I merely did this because EAPI=1 ebuilds
needed to be tagged as such in an EAPI="prefix" ebuild, and the features
EAPI="prefix" adds are ortogonal on the features EAPI=0 or EAPI=1 ...
provides.  As a result I now have EAPI="prefix 1" ebuilds.

Since you seem to argue here that EAPIs are not orderable, I get the
impression you imply these "combinations" of EAPIs to be desirable.  In
that case, what would the extension of the ebuild be like?


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]

On Tue, 18 Dec 2007 10:36:30 +0100
Fabian Groffen <grobian@gentoo.org> wrote:
> On 18-12-2007 00:39:38 +0000, Ciaran McCreesh wrote:
> > An EAPI is not limited to a numeric name. We could call the next
> > EAPI "cabbage" if we wanted to. There're already various
> > experimental EAPIs that don't use pure numbers (for example,
> > "paludis-1").
> > 
> > (Sometimes I think the next EAPI *should* be called "cabbage", if
> > only because it'll help disabuse people of the notion that EAPIs are
> > orderable...)
> 
> While I feel there has been given little to no attention to what
> EAPI's really are and how they relate to each other, I prefer to go
> this route myself as well.  The EAPI "name" should represent the
> feature(s) it adds.

EAPIs don't correspond to features either though.

> However, because "features" need not to include previous ones (why
> would they?), in the Prefix branch of Portage I implemented EAPI to
> be a space separated list.  I merely did this because EAPI=1 ebuilds
> needed to be tagged as such in an EAPI="prefix" ebuild, and the
> features EAPI="prefix" adds are ortogonal on the features EAPI=0 or
> EAPI=1 ... provides.  As a result I now have EAPI="prefix 1" ebuilds.
> 
> Since you seem to argue here that EAPIs are not orderable, I get the
> impression you imply these "combinations" of EAPIs to be desirable.
> In that case, what would the extension of the ebuild be like?

Combinations of features and rules is desirable. An EAPI can be thought
of as a collection of said features and rules (and that's how EAPIs are
worded in PMS, and largely how they're implemented in Paludis). But
developers shouldn't really be picking and choosing at that level
themselves -- adding new EAPIs that merely add one thing to a previous
EAPI (as 1 did to 0) is cheap.

Plus, we're back to the whole combination issue raised with eclasses.
There's no guarantee that features from different EAPIs can be combined
in any sensible way. For example (and I hope this doesn't happen...)
EAPI 2 might add a new IDEPEND variable, and then EAPI 3 might replace
*DEPEND with the single DEPENDENCIES + labels. You couldn't then say
that you want both IDEPEND and DEPENDENCIES, since they're largely
mutually incompatible.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Fabian Groffen]

On 18-12-2007 10:03:56 +0000, Ciaran McCreesh wrote:
> > However, because "features" need not to include previous ones (why
> > would they?), in the Prefix branch of Portage I implemented EAPI to
> > be a space separated list.  I merely did this because EAPI=1 ebuilds
> > needed to be tagged as such in an EAPI="prefix" ebuild, and the
> > features EAPI="prefix" adds are ortogonal on the features EAPI=0 or
> > EAPI=1 ... provides.  As a result I now have EAPI="prefix 1" ebuilds.
> > 
> > Since you seem to argue here that EAPIs are not orderable, I get the
> > impression you imply these "combinations" of EAPIs to be desirable.
> > In that case, what would the extension of the ebuild be like?
> 
> Combinations of features and rules is desirable. An EAPI can be thought
> of as a collection of said features and rules (and that's how EAPIs are
> worded in PMS, and largely how they're implemented in Paludis). But
> developers shouldn't really be picking and choosing at that level
> themselves -- adding new EAPIs that merely add one thing to a previous
> EAPI (as 1 did to 0) is cheap.

Just to have it spelt out, what you suggest here is that EAPI has a
single value, a word or a number, that refers to a set of "features and
rules", if I understand correctly.

With this way of using EAPI I fail to see why EAPIs aren't orderable.
Even with the example you gave in the previous mail, it looks like a
perfect succession of EAPIs.

However, I realise that this discussion is stricktly said off-topic for
the GLEP at hand, as this stuff hasn't been dealt with in the main tree
(yet).  In the end I guess it's a matter of opening up a new can of
worms, or trying to keep it simple and see how far you'll get with it.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

On Tue, 18 Dec 2007 21:38:08 +0100
Fabian Groffen <grobian@gentoo.org> wrote:
> Just to have it spelt out, what you suggest here is that EAPI has a
> single value, a word or a number, that refers to a set of "features
> and rules", if I understand correctly.
> 
> With this way of using EAPI I fail to see why EAPIs aren't orderable.
> Even with the example you gave in the previous mail, it looks like a
> perfect succession of EAPIs.

It doesn't *have* to be a perfect succession. It's entirely possible
that there will be, say, two divergent EAPI branches or even that there
will be a completely unrelated new EAPI format.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Ciaran McCreesh wrote:
> On Tue, 18 Dec 2007 21:38:08 +0100
> Fabian Groffen <grobian@gentoo.org> wrote:
>> Just to have it spelt out, what you suggest here is that EAPI has a
>> single value, a word or a number, that refers to a set of "features
>> and rules", if I understand correctly.
>>
>> With this way of using EAPI I fail to see why EAPIs aren't orderable.
>> Even with the example you gave in the previous mail, it looks like a
>> perfect succession of EAPIs.
> 
> It doesn't *have* to be a perfect succession. It's entirely possible
> that there will be, say, two divergent EAPI branches or even that there
> will be a completely unrelated new EAPI format.
> 

What's the point in having such thing?

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

On Wed, 19 Dec 2007 15:18:28 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> > It doesn't *have* to be a perfect succession. It's entirely possible
> > that there will be, say, two divergent EAPI branches or even that
> > there will be a completely unrelated new EAPI format.
> 
> 
> What's the point in having such thing?

The most likely case: if it's decided to have a substantially different
new EAPI and incompatible for adding lots of shiny new things like
multiABI, whilst keeping the existing EAPI series and extending it for
people who don't have time to convert their packages to the new format.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Thomas de Grenier de Latour]

On 2007/12/18, Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Mon, 17 Dec 2007 17:10:46 -0700
> Joe Peterson <lavajoe@gentoo.org> wrote:
> > I probably missed some of the stuff leading up to this GLEP, but
> > what is the problem with having the EAPI in the file and
> > determining it by looking at the file contents?
> 
> Motivation, second bullet point:
> 
> | Possibility to extend the behaviour of inherit and add new global
> | scope functions (as a result of not sourcing ebuilds with
> | unsupported EAPI).

Why can't it be in the file but readable without sourcing? For instance,
it could be mandatory that EAPI=X, if present, must be the first
non-blank and non-comment line of the ebuild (and it would then be
checked after sourcing, if the ebuild is sourced, to bug on cases where
it's redefined or unset afterwards).

-- 
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

On Tue, 18 Dec 2007 01:36:51 +0100
Thomas de Grenier de Latour <degrenier@easyconnect.fr> wrote:
> Why can't it be in the file but readable without sourcing? For
> instance, it could be mandatory that EAPI=X, if present, must be the
> first non-blank and non-comment line of the ebuild (and it would then
> be checked after sourcing, if the ebuild is sourced, to bug on cases
> where it's redefined or unset afterwards).

That's another option. It's considered less ideal because it's a nasty
hack -- it imposes restrictions beyond "it's bash" upon the format of
ebuilds.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Joe Peterson]

Ciaran McCreesh wrote:
> On Tue, 18 Dec 2007 01:36:51 +0100
> Thomas de Grenier de Latour <degrenier@easyconnect.fr> wrote:
>> Why can't it be in the file but readable without sourcing? For
>> instance, it could be mandatory that EAPI=X, if present, must be the
>> first non-blank and non-comment line of the ebuild (and it would then
>> be checked after sourcing, if the ebuild is sourced, to bug on cases
>> where it's redefined or unset afterwards).
> 
> That's another option. It's considered less ideal because it's a nasty
> hack -- it imposes restrictions beyond "it's bash" upon the format of
> ebuilds.

This option is worth thinking about more - there may be satisfactory
ways to mediate the issues.  It is certainly more elegant, and it avoids
another nasty gotcha: that of the pre-source and post-source EAPI
disagreeing.  Generally, I find that having the same info in two places
should be avoided whenever possible.  I know the GLEP contains ways of
determining the "real" EAPI in this case (post-source), but I can
imagine most humans will simply get used to looking at the filename and
potentially miss the fact that it doesn't match, and programs that look
only pre-source can be mislead.

					-Joe
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

On Mon, 17 Dec 2007 18:05:23 -0700
Joe Peterson <lavajoe@gentoo.org> wrote:
> This option is worth thinking about more - there may be satisfactory
> ways to mediate the issues.  It is certainly more elegant

Introducing new parse and format requirements upon bash files is most
definitely not elegant... Everything that currently tries to parse bash
that is itself not bash is full of weird bugs. And imposing weird and
arbitrary requirements about whitespace, positioning etc is far more
prone to developer screwup than the filename approach.

> and it avoids another nasty gotcha: that of the pre-source and
> post-source EAPI disagreeing.  Generally, I find that having the same
> info in two places should be avoided whenever possible.  I know the
> GLEP contains ways of determining the "real" EAPI in this case
> (post-source), but I can imagine most humans will simply get used to
> looking at the filename and potentially miss the fact that it doesn't
> match, and programs that look only pre-source can be mislead.

The GLEP's rules are merely to ensure a sane upgrade path. EAPI being
specified in two sets of places will only happen if a developer screws
up and ignores warnings from QA tools.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Joe Peterson]

Ciaran McCreesh wrote:
> On Mon, 17 Dec 2007 18:05:23 -0700
> Joe Peterson <lavajoe@gentoo.org> wrote:
>> This option is worth thinking about more - there may be satisfactory
>> ways to mediate the issues.  It is certainly more elegant
> 
> Introducing new parse and format requirements upon bash files is most
> definitely not elegant... Everything that currently tries to parse bash
> that is itself not bash is full of weird bugs. And imposing weird and
> arbitrary requirements about whitespace, positioning etc is far more
> prone to developer screwup than the filename approach.

I agree that such rules should not be arbitrary or depend on whitespace.
 It should behave essentially the same as sourcing the file.  But I do
agree that this is not trivial.

What about storing a copy of the EAPI in the Manifest file - when
"ebuild ... digest" is done?  That way, it will always match the one
authoritative "post-source" EAPI setting, since changing the ebuild will
require a new digest run anyway.  We have control over the format of
Manifest, so parsing it can be fast.

If Manifest is not a good candidate, put them in an optional "EAPI" file
(which can then also be included in the Manifest).  If the external EAPI
info for an ebuild is not found, then drop back to assuming it does not
have a defined pre-source EAPI.

This way, we can guarantee that the pre-source EAPI info matches the
post-source, since it was derived from it (during the digest step).
Forgive me if this idea has already been suggested.

> The GLEP's rules are merely to ensure a sane upgrade path. EAPI being
> specified in two sets of places will only happen if a developer screws
> up and ignores warnings from QA tools.

Yes, but I bet we can do better than that.

					-Joe
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Marius Mauch]

On Mon, 17 Dec 2007 18:46:12 -0700
Joe Peterson <lavajoe@gentoo.org> wrote:

> What about storing a copy of the EAPI in the Manifest file - when
> "ebuild ... digest" is done?  That way, it will always match the one
> authoritative "post-source" EAPI setting, since changing the ebuild
> will require a new digest run anyway.  We have control over the
> format of Manifest, so parsing it can be fast.

No chance.

> If Manifest is not a good candidate, put them in an optional "EAPI"
> file (which can then also be included in the Manifest).  If the
> external EAPI info for an ebuild is not found, then drop back to
> assuming it does not have a defined pre-source EAPI.

While I also dislike using the filename extension this would be an even
greater mess (we're trying to reduce the number of files in the
repository, so adding another 20k tiny files would require an
extremely good reason).

My personal opinion is that EAPI is the wrong angle to solve the
issue with versioning, that's something that should be dealt with at
the repository level (as it will eventually impact comparison rules
between "old-style" versions as well, and those by definition can't be
changed on a per-package base).
That leaves the argument about global-scope functions, for which there
are workarounds (not solutions), and without actual use cases it's a
bit hard to evaluate cost and benefits.

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

On Tuesday 18 December 2007 01:36:51 Thomas de Grenier de Latour wrote:
> Why can't it be in the file but readable without sourcing? For instance,
> it could be mandatory that EAPI=X, if present, must be the first
> non-blank and non-comment line of the ebuild (and it would then be
> checked after sourcing, if the ebuild is sourced, to bug on cases where
> it's redefined or unset afterwards).

This would also mean we had to wait for ages before taking advantage of it 
because old versions of portage still would try to source the ebuild when the 
EAPI is unknown. The nice thing about .ebuild-EAPI is that old versions of 
Portage will ignore it.

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Thomas de Grenier de Latour]

On 2007/12/18, Bo Ørsted Andresen <bo.andresen@zlin.dk> wrote:

> On Tuesday 18 December 2007 01:36:51 Thomas de Grenier de Latour
> wrote:
> > Why can't it be in the file but readable without sourcing? For
> > instance, it could be mandatory that EAPI=X, if present, must be
> > the first non-blank and non-comment line of the ebuild (and it
> > would then be checked after sourcing, if the ebuild is sourced, to
> > bug on cases where it's redefined or unset afterwards).
> 
> This would also mean we had to wait for ages before taking advantage
> of it because old versions of portage still would try to source the
> ebuild when the EAPI is unknown. The nice thing about .ebuild-EAPI is
> that old versions of Portage will ignore it.

There's no need to introduce a potential infinity of new files
extensions for that.  A single one is enough: just call files which 
use the rule i've proposed "foo.gbuild" instead of "foo.ebuild", and
you're done.  Imo, it would keep the tree more pleasant looking, and
limit complexity of the required changes on the existing scripts and
tools which are not already linked to libpaludis or alike.

-- 
TGL.
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Piotr Jaroszyński]

On Tuesday 18 of December 2007 22:08:52 Thomas de Grenier de Latour wrote:
> extensions for that.  A single one is enough: just call files which
> use the rule i've proposed "foo.gbuild" instead of "foo.ebuild",

or .ebuild-ng.

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Wulf C. Krueger]

[-- Attachment #1: Type: text/plain, Size: 181 bytes --]

On Tuesday, 18. December 2007 22:32:03 Piotr Jaroszyński wrote:
> or .ebuild-ng.

/me votes for .ebuild-TOS. ;)

-- 
Best regards, Wulf "Sorry, couldn't resist." Krueger :)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

On Tue, 18 Dec 2007 22:08:52 +0100
Thomas de Grenier de Latour <degrenier@easyconnect.fr> wrote:
> There's no need to introduce a potential infinity of new files
> extensions for that.  A single one is enough: just call files which 
> use the rule i've proposed "foo.gbuild" instead of "foo.ebuild", and
> you're done.

You're done until someone wants to introduce a change large enough that
it breaks the dodgy pattern matching package managers are doing to get
the EAPI currently. Which isn't that unlikely -- consider the original
purpose for metadata.xml for an example.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Thomas de Grenier de Latour]

On 2007/12/19, Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Tue, 18 Dec 2007 22:08:52 +0100
> Thomas de Grenier de Latour <degrenier@easyconnect.fr> wrote:
> > There's no need to introduce a potential infinity of new files
> > extensions for that.  A single one is enough: just call files which 
> > use the rule i've proposed "foo.gbuild" instead of "foo.ebuild", and
> > you're done.
> 
> You're done until someone wants to introduce a change large enough
> that it breaks the dodgy pattern matching package managers are doing
> to get the EAPI currently. 

You're done as long as ebuilds are written in bash. If there ever is
a new xml-based format, or whatever else, then yes, a third extension
will be needed. I don't see that as an argument for introducing an 
infinity of extensions right now though.

-- 
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

On Wed, 19 Dec 2007 08:12:24 +0100
Thomas de Grenier de Latour <degrenier@easyconnect.fr> wrote:
> You're done as long as ebuilds are written in bash.

Not even that. What if people decide that rather than writing
EAPI="blah", "eapi blah" is cleaner? What if metadata is moved out of
the ebuild, as some people started doing years ago?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Thomas de Grenier de Latour]

On 2007/12/19, Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Wed, 19 Dec 2007 08:12:24 +0100
> Thomas de Grenier de Latour <degrenier@easyconnect.fr> wrote:
> > You're done as long as ebuilds are written in bash.
> 
> Not even that. What if people decide that rather than writing
> EAPI="blah", "eapi blah" is cleaner? 

Yeah, and file names suffixes won't work anymore as soon as it has 
arbitrarily been decided that prefixes should be used instead, or that
EAPI must disappear because using explicit sets of named features is
better than using names of some particular sets. That rules only holds
as long as they don't change is not an argument, but a truism.

> What if metadata is moved out of the ebuild, as some people started
> doing years ago?

Which metadata's, the ones from the file contents or the ones from the
file name?

Seriously, i still don't see the start of a rational argument in
your objections to an in-contents alternative.
Which lets the subjective disagreement (you prefering to keep bash
syntax unrestricted at the price of encumbered files names, and me
prefering to restrict it on one particular line for keeping clean
"name-version.fixed-extension" files names), for which argumentation
is hopeless too.

-- 
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

On Thu, 20 Dec 2007 06:46:44 +0100
Thomas de Grenier de Latour <degrenier@easyconnect.fr> wrote:
> On 2007/12/19, Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk>
> wrote:
> > On Wed, 19 Dec 2007 08:12:24 +0100
> > Thomas de Grenier de Latour <degrenier@easyconnect.fr> wrote:
> > > You're done as long as ebuilds are written in bash.
> > 
> > Not even that. What if people decide that rather than writing
> > EAPI="blah", "eapi blah" is cleaner? 
> 
> Yeah, and file names suffixes won't work anymore as soon as it has 
> arbitrarily been decided that prefixes should be used instead, or that
> EAPI must disappear because using explicit sets of named features is
> better than using names of some particular sets. That rules only holds
> as long as they don't change is not an argument, but a truism.

Uh, it works in both those cases. The package manager will simply not
see the ebuild at all.

Which is pretty much the point...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Thomas de Grenier de Latour]

On 2007/12/20, Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> Uh, it works in both those cases. The package manager will simply not
> see the ebuild at all.
>
> Which is pretty much the point...

Yes, because a change in the way EAPI is read implies a change in the
files naming rule, so that the PM recognize the file only if it can
do something useful with it.  That's true for both proposals, which
was pretty much my point.  And that thus, it was not an argument in
favor of one against the other.

I still think that changing file names when absolutly required
(switching from "EAPI=foo" to "eapi foo", or moving it elsewhere, or
switching to xml, etc.) is less disturbing than changing it for every
single new EAPI. It's not because one new extension may not be
eternally enough that we should introduce an infinity right now.

But yeah, to be honest, you're right that my original "as long as
ebuilds stay bash" was a bit optimistic: it was assuming there would 
be no decision of changing that rule as long as there would be no good
reason for it (like a switch to xml or whatever other not-bash format).

-- 
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Michael Haubenwallner]

On Thu, 2007-12-20 at 14:08 +0100, Thomas de Grenier de Latour wrote:
<snip>

Seems that there is a chain of different metadata levels:

1) The parser/interpreter/compiler/whatever to grok the ebuild.
2) *How* to extract the EAPI value from the ebuild(-filename), using 1)
3) The *value* of EAPI for that ebuild, using 2)
4) The contents of the ebuild, based on 3)

To 1: for me it's absolutely acceptable to have it encoded in the
filename (or extension). Fex we want to switch from bash to xml (for
whatever reason), we could rename from *.ebuild to *.xbuild.

> But yeah, to be honest, you're right that my original "as long as
> ebuilds stay bash" was a bit optimistic: it was assuming there would 
> be no decision of changing that rule as long as there would be no good
> reason for it (like a switch to xml or whatever other not-bash
> format).

To 2: it might be acceptable to have it encoded into the filename.

To 3 (and 2): Thomas++

> I still think that changing file names when absolutly required
> (switching from "EAPI=foo" to "eapi foo", or moving it elsewhere, or
> switching to xml, etc.) is less disturbing than changing it for every
> single new EAPI. It's not because one new extension may not be
> eternally enough that we should introduce an infinity right now.

To 4: we agree that this never will be encoded in the filename ;)


Just another bit of brainstorm (forget it if too broken):

What if we do not start with "EAPI=1" variable, but "eapi 1" function
immediately ?

I could think of several implementations to let PM detect EAPI:

*) Given it is the first bash-command in the ebuild:
Just 'echo' the required EAPI and exit while PM is in "look-for-eapi"
mode (remember 'eapi' function is part of PM, or profile.bashrc as
fallback for ancient PM).

*) As 'eapi' being a bash function, it could *migrate* the
bash-environment from the PM's default EAPI to the given one - or just
spit "cannot migrate EAPI from A to B"...

*) Or just spit a message "update your PM" (from profile.bashrc) ...

Just want to show that using 'eapi-function' should be more flexible
than 'EAPI-variable', and thus will not be subject to change too often
and require 2) (see above).

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

On Thu, 20 Dec 2007 16:57:54 +0100
Michael Haubenwallner <haubi@gentoo.org> wrote:
> What if we do not start with "EAPI=1" variable, but "eapi 1" function
> immediately ?

Uhhhhh. Then we're back to the zillion months wait before people can
use anything.

> *) Given it is the first bash-command in the ebuild:
> Just 'echo' the required EAPI and exit while PM is in "look-for-eapi"
> mode (remember 'eapi' function is part of PM, or profile.bashrc as
> fallback for ancient PM).

There isn't a look for eapi mode.

> *) As 'eapi' being a bash function, it could *migrate* the
> bash-environment from the PM's default EAPI to the given one - or just
> spit "cannot migrate EAPI from A to B"...

Uh... No it couldn't. And there's no default EAPI.

> *) Or just spit a message "update your PM" (from profile.bashrc) ...

Uh... No it couldn't.

Please don't comment any further until you understand how this whole
thing works.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 2187 bytes --]

Ciaran McCreesh wrote:
> Please don't comment any further until you understand how this whole
> thing works.
> 

I think this is a bit of an unrealistic expectation.  This change
impacts EVERYBODY - devs, users, etc.  To expect people not to comment
on it simply because they're not qualified to write a package manager is
a bit naive.  Like it or not you do need to obtain some kind of general
agreement before making a change of this magnitude.

Even so - I'm impressed about how civil this discussion has actually
remained.

Feel free to continue to make your points, but a GLEP requires some kind
of census - not just silence after everybody gets tired of hitting
reply.  If somebody doesn't know what they're talking about - persuade
them - don't just tell them to be quiet.

I usually like to look at stuff like this in terms of pros and cons.  So
here are the pros and cons I can see regarding this change:

PRO:
Very simple to determine the EAPI of an ebuild - regardless of what is
inside
Works with existing PMs
Simple

CON:
Yet another value to be parsed out of an increasingly-complex filename.
Doesn't look pretty  :)
Makes a low-level detail more visible to users.
You can't make a wild change to how EAPIs are specified - since old PMs
will expect it to be in the filename in a particular format.

The other option that seems popular is just continuing with EAPI=1 or
whatever in the file (likely with a restriction on format that makes it
parsable without BASH).  I see these pros/cons for this solution:

PRO:
Very simple to determine the EAPI of an ebuild - regardless of what is
inside
Works with existing PMs
Simple
Doesn't add another field to the filename - reducing complexity
Not very visible to users
Looks pretty :)

CON:
You can't make a wild change to how EAPIs are specified - since old PMs
will expect it to be inside the file in a particular format.

I don't see how the latter is any worse than the former - its main
limitation applies to both methods - just in a different place.  I think
you'd get far more consensus to the latter approach.  And if for
whatever reason this fails way down the road it could always be moved to
the filename at that time.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]

On Fri, 21 Dec 2007 08:43:43 -0500
Richard Freeman <rich@thefreemanclan.net> wrote:
> Ciaran McCreesh wrote:
> > Please don't comment any further until you understand how this whole
> > thing works.
> 
> I think this is a bit of an unrealistic expectation.  This change
> impacts EVERYBODY - devs, users, etc.  To expect people not to comment
> on it simply because they're not qualified to write a package manager
> is a bit naive.  Like it or not you do need to obtain some kind of
> general agreement before making a change of this magnitude.

What. It's a small change that's only visible to developers and power
users.

> CON:
> Yet another value to be parsed out of an increasingly-complex
> filename. Doesn't look pretty  :)

It'd only increase complexity in any meaningful way if it were part of
the version part of the ebuild. The version part *is* getting pretty
tricky to parse correctly.

> Makes a low-level detail more visible to users.

Users don't see .ebuild files.

> You can't make a wild change to how EAPIs are specified - since old
> PMs will expect it to be in the filename in a particular format.

You can make entirely arbitrary changes to EAPIs with suffixes,
provided only that you don't use either .ebuild
or .ebuild-(any-existing-eapi).

> The other option that seems popular is just continuing with EAPI=1 or
> whatever in the file (likely with a restriction on format that makes
> it parsable without BASH).  I see these pros/cons for this solution:
> 
> CON:
> You can't make a wild change to how EAPIs are specified - since old
> PMs will expect it to be inside the file in a particular format.

Bigger con: it means no non-trivial new EAPIs for a year or more.

Another con: EAPI=foo or EAPI="foo" or export EAPI="foo" or what?

> I think you'd get far more consensus to the latter approach.

Yes, but the latter problem doesn't solve anything, so it doesn't
really matter whether or not people like it -- it's utterly pointless.

Counting pros and cons is a bad idea -- a single con can make an idea
completely worthless, whilst ten trivial "it doesn't look quite as
pretty cons" are largely meaningless.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> posted
20071221135922.3781ecdd@blueyonder.co.uk, excerpted below, on  Fri, 21 Dec
2007 13:59:22 +0000:

> On Fri, 21 Dec 2007 08:43:43 -0500
> Richard Freeman <rich@thefreemanclan.net> wrote:
>> Ciaran McCreesh wrote:
>> > Please don't comment any further until you understand how this whole
>> > thing works.
>> 
>> I think this is a bit of an unrealistic expectation.  This change
>> impacts EVERYBODY - devs, users, etc.

> What. It's a small change that's only visible to developers and power
> users.

But it affects all developers (and power users) in the routine way they 
do their job, dealing with ebuilds (or ebuilds plus whatever, if this 
GLEP goes thru).  As such, it's a "big" change, because it affects how a 
lot of people do their routine work.

Yes, that's quibbling over semantics and viewpoint, but it's obvious 
/some/ people consider it a big change, big enough for them to make a big 
deal about, anyway, which is what matters in terms of discussion and 
ultimate acception/rejection of the GLEP.

>> Makes a low-level detail more visible to users.
> 
> Users don't see .ebuild files.

"Gentoo users", as often used in the context of this list (from my 
observation), do.  "Gentoo users" are, as used here, "Gentoo system 
sysadmins" by another name.  As such, they've always been expected to be 
at what the general IT world would consider at minimum "power user", 
certainly not the "luser" that's the general IT world's usage of "user".  
By definition, "Gentoo users" are expected to be able to RTFM, and 
expected to actually /enjoy/ the extra control of being able to mess with 
ebuild files and the like.  Otherwise, why are they using Gentoo at all, 
when it's targeted at that "power user", and there are other 
distributions out there directly targeted at the "(l)user" level?

So, "users", as used on this list, *do* see ebuild files, or at minimum, 
cannot be reasonably said *not* to see them, since many of them in fact 
do see them and make use of them, in overlays and the like.

As for the generally IT world usage of the term, (l)user, that doesn't 
come up so often here, because it's not what we deal with.  Dealing with 
them would be the job of /our/ users -- Gentoo sysadmins by another name.

>> You can't make a wild change to how EAPIs are specified - since old PMs
>> will expect it to be in the filename in a particular format.
> 
> You can make entirely arbitrary changes to EAPIs with suffixes, provided
> only that you don't use either .ebuild or .ebuild-(any-existing-eapi).

OK, first, a comment on the GLEP itself:  I just looked at it again, and 
realized it doesn't actually /specify/ the name format in so many words 
or in commonly accepted syntax form.  One can see what's expected based 
on the /examples/, but it's not specified... anywhere that I could see.

So the GLEP needs something like the below (may not be technically 
correct, but as an example to be corrected as necessary when added to the 
GLEP) syntax specified:

<PF>.ebuild[-<suffix>]

IMO that's the key to beginning to clear up my (I think former) 
confusion.  Without that clearly stated, I was conflating the two 
possible changes, the one given by the GLEP, and the one left unspec-ed, 
and thus reserved for the future and/or other non-Gentoo usage, 
extensions /other/ than .ebuild[-<suffix>].

Given the conflation, I was then left confused by the GLEP requirement 
that the EAPI not be changed from that found in the filename (with the 
filename EAPI defaulting to 0 if not given), set against the argument 
that EAPI could then at some point be made dynamic, or otherwise less 
firmly specified than filename semantics requires.  Separating the 
concepts, then, clears up the confusion, since the possibility is left 
open to change to something /other/ than .ebuild[-<suffix], say fbuild, 
in the future (or for other than main Gentoo tree) as necessary, and the 
new (fbuild or whatever) format would be free to break all the current 
rules associated with .ebuild[-<suffix>] as deemed necessary.

So now I see how you could state they must remain the same (in the glep) 
yet allow for dynamically setting them ("post-source") in future non-
ebuild* formats.

Further suggestion for the GLEP, then: In addition to specifying syntax 
explicitly, note explicitly as well, that this glep deals with .ebuild* 
only, and that one possible mechanism for future incompatible changes 
would therefore be to change the extension to something other 
than .ebuild*.

This should eliminate an entire class of objections (and simple 
confusion), including my main previous one, due to the present less than 
clear specification and the confusion it caused.

(/NOW/ I see...! =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Steve Long]

Duncan wrote:
<snip>
> our users -- Gentoo sysadmins by another name.

THANK YOU! Finally someone said it (and explained it better than I could.)
All our users-- the ones who deal with the glitches that can arise in a
source distro which binary users never see-- have the skill level of an
admin anywhere else.

It might take someone two or three months to get the basics on Gentoo, but
if you can manage a manual install and maintain a Gentoo box, no-one should
be sneering at you (especially as they started out knowing nothing too.)

> Without that clearly stated, I was conflating the two
> possible changes, the one given by the GLEP, and the one left unspec-ed,
> and thus reserved for the future and/or other non-Gentoo usage,
> extensions /other/ than .ebuild[-<suffix>].
>
Interesting: it brings up the possibility of simply using another extension
for files with eapi encoded in the name, and leaving the existing .ebuild
to continue as is.

PMs which don't support versioning would ignore them, since they're
not .ebuild, and existing tools would need the same changes as
with .ebuild-foo; .eapi-foo ?

> Given the conflation, I was then left confused by the GLEP requirement
> that the EAPI not be changed from that found in the filename (with the
> filename EAPI defaulting to 0 if not given), set against the argument
> that EAPI could then at some point be made dynamic, or otherwise less
> firmly specified than filename semantics requires.

But this would have to be based on /some/ sort of eapi suffix in the
filename, or the file would be sourced by current (not future) versions of
portage (the reason for changing the suffix in the first place.) Given that
why not just use the same in the ebuild EAPI="foo" declaration, with the
proviso that it's restricted to only appearing once in the file?

Still seems much cleaner to me. <sarcasm;> Oh yeah, we have to do this *now*
we can't wait 6 months or so, because there are tons of apps that our users
need, which they can't get without ebuilds using an api which can't be
sourced.</sarcasm>

This is supposed to be about the longer-term, not rushing through changes:
it won't exactly take long to get a version of portage that doesn't
automatically source ebuild files: it can just take the first EAPI line it
finds and not source anything it doesn't know about. As ever the maintainer
takes ultimate responsibility for ensuring their ebuild works, and the QA
tool can trivially confirm that there's only one EAPI declaration.
eg, this finds all ebuilds which have more than one SLOT declaration:
find /usr/portage -type f -name '*.ebuild' -exec bash -c 'for f; do
c=$(grep -c "\bSLOT=" "$f"); ((c>1)) && grep -H SLOT "$f"; done' _ {} +
[all one line]

It's not foolproof (gives false positives eg comments) so I'd use that other
regex for EAPI and put some faith in the maintainers (and the
commit-reviews.)

Oh yeah I forgot, McCreesh thinks they're all idiots[1], so let's just do
what he says. Funny thing is I think the USE-flag metadata thing would have
breezed through as a GLEP; I don't recall one person saying they thought it
was a bad idea.

[1]
http://lab.obsethryl.eu/content/paludis-gentoo-and-ciaran-mccreesh-uncensored


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

On Sat, 22 Dec 2007 06:35:07 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Oh yeah I forgot, McCreesh thinks they're all idiots[1]

No no. I think some of them are idiots. Get it right.

> Funny thing is I think the USE-flag metadata
> thing would have breezed through as a GLEP; I don't recall one person
> saying they thought it was a bad idea.

But you do recall people saying how it needed extending to be useful.
Yes, it would have breezed through as a GLEP, but it would have had a
half dozen small additions that would have made it a lot more useful.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> posted
20071222071228.1e2da808@blueyonder.co.uk, excerpted below, on  Sat, 22 Dec
2007 07:12:28 +0000:

>> Funny thing is I think the USE-flag metadata thing would have breezed
>> through as a GLEP; I don't recall one person saying they thought it was
>> a bad idea.
> 
> But you do recall people saying how it needed extending to be useful.
> Yes, it would have breezed through as a GLEP, but it would have had a
> half dozen small additions that would have made it a lot more useful.

++, as I think pretty much everybody agrees at this point.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

Steve Long <slong@rathaus.eclipse.co.uk> posted
fkiasm$3be$1@ger.gmane.org, excerpted below, on  Sat, 22 Dec 2007 06:35:07
+0000:

> Oh yeah I forgot, McCreesh thinks they're all idiots[1], so let's just
> do what he says.

> [1]
> http://lab.obsethryl.eu/content/paludis-gentoo-and-ciaran-mccreesh-
uncensored

I read the same interview and didn't take it like that, but regardless, 
why are you dropping this discussion to a new low?  Until you came along, 
altho there was disagreement, people were at least maintaining some 
civility in the discussion.  Then you come along, and I see multiple 
personal attack posts.  That's not right, and until now, we'd avoided it.

Please apologize.  Just because you don't agree with someone doesn't mean 
you have to take it to the level you just have, and it does NOT help.  (I 
thank you for your agreement with me, as it happens, disagreeing with 
Ciaran, on the users thing, but again, we had kept it civil.  Here, you 
aren't, and it doesn't belong on the list, and regardless of whether you 
just agreed with me or not, you need called on it, and I don't see any 
other posts doing it yet, so...)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Steve Long]

Duncan wrote:
> Steve Long <slong@rathaus.eclipse.co.uk> posted
> fkiasm$3be$1@ger.gmane.org, excerpted below, on  Sat, 22 Dec 2007 06:35:07
> +0000:
> 
>> Oh yeah I forgot, McCreesh thinks they're all idiots[1], so let's just
>> do what he says.
> 
>> [1]
>> http://lab.obsethryl.eu/content/paludis-gentoo-and-ciaran-mccreesh-
> uncensored
> 
> I read the same interview and didn't take it like that, but regardless,
> why are you dropping this discussion to a new low?  Until you came along,
> altho there was disagreement, people were at least maintaining some
> civility in the discussion.  Then you come along, and I see multiple
> personal attack posts.  That's not right, and until now, we'd avoided it.
> 
> Please apologize.  Just because you don't agree with someone doesn't mean
> you have to take it to the level you just have, and it does NOT help.  (I
> thank you for your agreement with me, as it happens, disagreeing with
> Ciaran, on the users thing, but again, we had kept it civil.  Here, you
> aren't, and it doesn't belong on the list, and regardless of whether you
> just agreed with me or not, you need called on it, and I don't see any
> other posts doing it yet, so...)
> 
I don't accept that I took it to that level, but I apologise unreservedly
for responding to it.


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

Steve Long <slong@rathaus.eclipse.co.uk> posted
fkmi0i$4dh$1@ger.gmane.org, excerpted below, on  Sun, 23 Dec 2007 21:01:15
+0000:

> I don't accept that I took it to that level, but I apologise
> unreservedly for responding to it.

Thanks.  Now to leave it behind.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Thomas Anderson]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

On Friday 21 December 2007 08:43:43 Richard Freeman wrote:
> Ciaran McCreesh wrote:
> > Please don't comment any further until you understand how this whole
> > thing works.
> CON:
> Yet another value to be parsed out of an increasingly-complex filename.
> Doesn't look pretty  :)
Taste is a matter of opinion. I happen to like eapi-1 in the filename so I 
know a bit about the ebuild before looking through its contents.
> Makes a low-level detail more visible to users.
> You can't make a wild change to how EAPIs are specified - since old PMs
> will expect it to be in the filename in a particular format.
This isn't a CON, it is actually a PRO because old PMs won't recognize the new 
format and everyone will be happy. (something not so easy with the other 
solutions.)


-- 
2.6.23-gentoo-r3

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Steve Long]

Thomas de Grenier de Latour wrote:

> On 2007/12/18, Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:
> 
>> On Mon, 17 Dec 2007 17:10:46 -0700
>> Joe Peterson <lavajoe@gentoo.org> wrote:
>> > I probably missed some of the stuff leading up to this GLEP, but
>> > what is the problem with having the EAPI in the file and
>> > determining it by looking at the file contents?
>> 
>> Motivation, second bullet point:
>> 
>> | Possibility to extend the behaviour of inherit and add new global
>> | scope functions (as a result of not sourcing ebuilds with
>> | unsupported EAPI).
> 
> Why can't it be in the file but readable without sourcing? For instance,
> it could be mandatory that EAPI=X, if present, must be the first
> non-blank and non-comment line of the ebuild (and it would then be
> checked after sourcing, if the ebuild is sourced, to bug on cases where
> it's redefined or unset afterwards).
>
There's _no_ need to source, nor constrain like that, for a simple one-line
variable, eg: 
$ sed -nr '/^[[:space:]]*DESCRIPTION="([^"]*)".*/ { s//\1/p;q; }' \
     app-portage/autounmask/autounmask-0.21.ebuild
autounmask - Unmasking packages the easy way

eapi=$(sed -nr '/^[[:space:]]*EAPI="([^"]*)".*/ { s//\1/p;q; }' foo.ebuild)
[[ $eapi ]] && checkAPI "$eapi"
..would do it in bash (empty if unset in ebuild) assuming the conventional
EAPI="xx" format is used. Other languages can call system() easily enough.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 1971 bytes --]

On Tue, Dec 18, 2007 at 05:05:13PM +0000, Steve Long wrote:
> Thomas de Grenier de Latour wrote:
> 
> > On 2007/12/18, Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:
> > 
> >> On Mon, 17 Dec 2007 17:10:46 -0700
> >> Joe Peterson <lavajoe@gentoo.org> wrote:
> >> > I probably missed some of the stuff leading up to this GLEP, but
> >> > what is the problem with having the EAPI in the file and
> >> > determining it by looking at the file contents?
> >> 
> >> Motivation, second bullet point:
> >> 
> >> | Possibility to extend the behaviour of inherit and add new global
> >> | scope functions (as a result of not sourcing ebuilds with
> >> | unsupported EAPI).
> > 
> > Why can't it be in the file but readable without sourcing? For instance,
> > it could be mandatory that EAPI=X, if present, must be the first
> > non-blank and non-comment line of the ebuild (and it would then be
> > checked after sourcing, if the ebuild is sourced, to bug on cases where
> > it's redefined or unset afterwards).
> >
> There's _no_ need to source, nor constrain like that, for a simple one-line
> variable, eg: 
> $ sed -nr '/^[[:space:]]*DESCRIPTION="([^"]*)".*/ { s//\1/p;q; }' \
>      app-portage/autounmask/autounmask-0.21.ebuild
> autounmask - Unmasking packages the easy way
> 
> eapi=$(sed -nr '/^[[:space:]]*EAPI="([^"]*)".*/ { s//\1/p;q; }' foo.ebuild)
> [[ $eapi ]] && checkAPI "$eapi"
> ..would do it in bash (empty if unset in ebuild) assuming the conventional
> EAPI="xx" format is used. Other languages can call system() easily enough.

This is just *brillant*. Lets see how useful your solution is:

--- 8< ---
# EAPI has to be set differently based upon tests on PV
if [[ -z ${PV/?.?/} ]] ; then
	EAPI="bar-1"
elif [[ -z ${PV/?.?.?/} ]] ; then
	EAPI="0"
else
	EAPI="1"
fi
--- 8< ---

So please, no hacks.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Steve Long]

Fernando J. Pereda wrote:
>> > Why can't it be in the file but readable without sourcing?
>> >
>> There's _no_ need to source, nor constrain like that, for a simple
>> one-line variable, eg:
>> $ sed -nr '/^[[:space:]]*DESCRIPTION="([^"]*)".*/ { s//\1/p;q; }' \
>>      app-portage/autounmask/autounmask-0.21.ebuild
>> autounmask - Unmasking packages the easy way
>> 
>> eapi=$(sed -nr '/^[[:space:]]*EAPI="([^"]*)".*/ { s//\1/p;q; }'
>> foo.ebuild)
>> [[ $eapi ]] && checkAPI "$eapi"
>> ..would do it in bash (empty if unset in ebuild) assuming the
>> conventional EAPI="xx" format is used. Other languages can call system()
>> easily enough.
> 
> This is just *brillant*. Lets see how useful your solution is:
> 
> --- 8< ---
> # EAPI has to be set differently based upon tests on PV
Er, why exactly? Why not just have the new version of the ebuild declare a
new EAPI?
> if [[ -z ${PV/?.?/} ]] ; then
> EAPI="bar-1"
> elif [[ -z ${PV/?.?.?/} ]] ; then
> EAPI="0"
> else
> EAPI="1"
> fi
> --- 8< ---
> 
> So please, no hacks.
> 
Are you really telling me you are going to write _one_ ebuild with /that/
god-awful hackery in it?

If a new version of an ebuild uses a different EAPI, one would have thought
the changes to it-- to use that EAPI-- would mean a single EAPI declaration
is enough.

Sticking to a single EAPI="xx" format in the ebuild means we don't have the
*hack* of duplicating information in the filename (and the whole
{pre,post}src issue, QA checks for human error since this is redundant
info) simply to avoid parsing a config file.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

On Wed, 19 Dec 2007 10:26:16 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Are you really telling me you are going to write _one_ ebuild
> with /that/ god-awful hackery in it?

Are you really suggesting that no-one ever will?

> Sticking to a single EAPI="xx" format in the ebuild means we don't
> have the *hack* of duplicating information in the filename (and the
> whole {pre,post}src issue, QA checks for human error since this is
> redundant info) simply to avoid parsing a config file.

There is no duplication of information, nor redundancy.

The pre/post source issue exists regardless of how EAPI is set -- it's
just that with filename EAPIs, you aren't restricted to post source
changes. It's explicit in the GLEP because it's important that package
mangers get it right, but it's not a new issue.

Ebuilds are not config files.

Really. It's a heck of a lot cleaner in the filename suffix.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Steve Long]

Ciaran McCreesh wrote:

> On Wed, 19 Dec 2007 10:26:16 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> Are you really telling me you are going to write _one_ ebuild
>> with /that/ god-awful hackery in it?
> 
> Are you really suggesting that no-one ever will?
>
They won't if the spec and the docs say it's restricted to a single
instance, which can be checked trivially by repoman. The example given was
contrived and not at all representative imo; for instance one could as
easily do the same kind of thing with DESCRIPTION, but it would be of
little use and just add confusion to no purpose.

>> Sticking to a single EAPI="xx" format in the ebuild means we don't
>> have the *hack* of duplicating information in the filename (and the
>> whole {pre,post}src issue, QA checks for human error since this is
>> redundant info) simply to avoid parsing a config file.
> 
> There is no duplication of information, nor redundancy.
>
So what were the QA checks you mentioned to confirm that the same EAPI is
set in both the filename and the ebuild, for-- if not integrity of
duplicated data?

> The pre/post source issue exists regardless of how EAPI is set -- it's
> just that with filename EAPIs, you aren't restricted to post source
> changes.
And what benefit does that provide, besides making it easier for your
package manager?

(I note this is a technical consideration of the implementation, given as a
reason to change a clean API-- with consequences for workflow.)

> It's explicit in the GLEP because it's important that package 
> mangers get it right, but it's not a new issue.
>
Sure.
 
> Ebuilds are not config files.
>
Indeed not, but they can be parsed as such for simple, core, metadata.
 
> Really. It's a heck of a lot cleaner in the filename suffix.
> 
Nah, it's an awful hack and you know it. It has nothing to do with package
naming and is unnecessary exposure of internal data. -rN is ok, and there
are rules on when and when not to bump rev; this is not. It's much cleaner
specified as part of the ebuild in the same way as DESCRIPTION, so long as
it is only specified once.

Or do you see some real benefit to specifying EAPI more than once as in the
example? If so, please share it.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 3638 bytes --]

On Wed, 19 Dec 2007 11:05:35 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 19 Dec 2007 10:26:16 +0000
> > Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> >> Are you really telling me you are going to write _one_ ebuild
> >> with /that/ god-awful hackery in it?
> > 
> > Are you really suggesting that no-one ever will?
> >
> They won't if the spec and the docs say it's restricted to a single
> instance, which can be checked trivially by repoman. The example
> given was contrived and not at all representative imo; for instance
> one could as easily do the same kind of thing with DESCRIPTION, but
> it would be of little use and just add confusion to no purpose.

Except people *do* have generated DESCRIPTION etc, and with good
reason. A simple example is the vim-spell-* packages.

> >> Sticking to a single EAPI="xx" format in the ebuild means we don't
> >> have the *hack* of duplicating information in the filename (and the
> >> whole {pre,post}src issue, QA checks for human error since this is
> >> redundant info) simply to avoid parsing a config file.
> > 
> > There is no duplication of information, nor redundancy.
> >
> So what were the QA checks you mentioned to confirm that the same
> EAPI is set in both the filename and the ebuild, for-- if not
> integrity of duplicated data?

It's to catch developers screwing up an unnecessarily specifying EAPI
manually. For example, someone might copy an EAPI 1 ebuild to
a .ebuild-2. But the only time that will happen is when there's a
screwup.

> > The pre/post source issue exists regardless of how EAPI is set --
> > it's just that with filename EAPIs, you aren't restricted to post
> > source changes.
>
> And what benefit does that provide, besides making it easier for your
> package manager?

It's not a question of ease. It's a question of being possible. You
need to understand the metadata generation process to understand why
the package manger has to assume a particular EAPI when generating the
metadata. Without the EAPI in the suffix, the assumed EAPI has to be
some weird combination of all existing and all possible future EAPIs --
which isn't logically sound.

> (I note this is a technical consideration of the implementation,
> given as a reason to change a clean API-- with consequences for
> workflow.)

No no. It's already an ebuild-visible issue, and there's no way it
can't be that doesn't involve imposing restrictions upon every single
possible future EAPI.

> > Ebuilds are not config files.
> >
> Indeed not, but they can be parsed as such for simple, core, metadata.

There is currently no information available from an ebuild that can be
parsed by any tool other than bash.

> > Really. It's a heck of a lot cleaner in the filename suffix.
> > 
> Nah, it's an awful hack and you know it. It has nothing to do with
> package naming and is unnecessary exposure of internal data. -rN is
> ok, and there are rules on when and when not to bump rev; this is
> not. It's much cleaner specified as part of the ebuild in the same
> way as DESCRIPTION, so long as it is only specified once.
> 
> Or do you see some real benefit to specifying EAPI more than once as
> in the example? If so, please share it.

And again, you show that you don't understand what's going on. EAPI is
only specified once except where developers screw up. The GLEP merely
moves the EAPI to being set *before* the metadata is generated, which
removes all the restrictions that having EAPI as part of the ebuild's
content imposes.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Steve Long]

Ciaran McCreesh wrote:
>> >> Are you really telling me you are going to write _one_ ebuild
>> >> with /that/ god-awful hackery in it?
>> > 
>> > Are you really suggesting that no-one ever will?
>> >
>> They won't if the spec and the docs say it's restricted to a single
>> instance, which can be checked trivially by repoman. The example
>> given was contrived and not at all representative imo; for instance
>> one could as easily do the same kind of thing with DESCRIPTION, but
>> it would be of little use and just add confusion to no purpose.
> 
> Except people *do* have generated DESCRIPTION etc, and with good
> reason. A simple example is the vim-spell-* packages.
>
OK. Do you think a generated EAPI is a good idea? I'm curious as to how that
would be reflected in the filename (as well as your reasons ofc.)

>> > The pre/post source issue exists regardless of how EAPI is set --
>> > it's just that with filename EAPIs, you aren't restricted to post
>> > source changes.
>>
>> And what benefit does that provide, besides making it easier for your
>> package manager?
> 
> It's not a question of ease. It's a question of being possible. You
> need to understand the metadata generation process to understand why
> the package manger has to assume a particular EAPI when generating the
> metadata. Without the EAPI in the suffix, the assumed EAPI has to be
> some weird combination of all existing and all possible future EAPIs --
> which isn't logically sound.
>
No: without knowing the EAPI when generating said data. If that needs to be
known relatively soon in order to generate the rest, extract it early. You
still only need to load the file from disk once, and you don't need to
source to get that data, given one simple restriction (only declaring it
once.)
 
>> (I note this is a technical consideration of the implementation,
>> given as a reason to change a clean API-- with consequences for
>> workflow.)
> 
> No no. It's already an ebuild-visible issue, and there's no way it
> can't be that doesn't involve imposing restrictions upon every single
> possible future EAPI.
>
The *reason* for the change is about the implementation, and it is not
necessary. I accept it would make metadata generation quicker, but the
end-user can already use -metadata-transfer atm and never need to run that
process. It would save many more cycles if more users did imo (optimising
early here seems silly tbh, given that paludis now requires ruby.)

Given that, as a user I see no benefit to my machines that would justify the
maintenance headache which I know as a coder this will result in. Quite
apart from all the changes to supporting tools and workflow, it's pushing
an implementation-specific datum into a namespace where it's neither needed
nor useful, apart from to the implementation. Someone working on an ebuild
will be looking at its text, and an end-user doesn't care.

Revision numbers are of note to all parties, by contrast.

>> > Ebuilds are not config files.
>> >
>> Indeed not, but they can be parsed as such for simple, core, metadata.
> 
> There is currently no information available from an ebuild that can be
> parsed by any tool other than bash.
>
OK, but restricting EAPI= across the board (in the way that others have
already asked for) and enforcing it via repoman would mean EAPI could
easily be extracted.

>> > Really. It's a heck of a lot cleaner in the filename suffix.
>> > 
>> Nah, it's an awful hack and you know it. It has nothing to do with
>> package naming and is unnecessary exposure of internal data. -rN is
>> ok, and there are rules on when and when not to bump rev; this is
>> not. It's much cleaner specified as part of the ebuild in the same
>> way as DESCRIPTION, so long as it is only specified once.
>> 
>> Or do you see some real benefit to specifying EAPI more than once as
>> in the example? If so, please share it.
> 
> And again, you show that you don't understand what's going on. EAPI is
> only specified once except where developers screw up. The GLEP merely
> moves the EAPI to being set *before* the metadata is generated, which
> removes all the restrictions that having EAPI as part of the ebuild's
> content imposes.
> 
Hmm I think you should consider the example that this sub-thread is about,
and whether an apology would be in order.

Since only declaring it the once /seems/ ok with you, what on Earth is so
hard about extracting it? I'm sure ruby has sufficient text processing
capability if the C++ is a bit much for you; I remember there was that
long-term bug in paludis not being able to deal with whitespace in config
files, so clearly something's up with your text-processing. Hope that's
finally fixed now.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 4102 bytes --]

On Thu, 20 Dec 2007 00:07:35 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > Except people *do* have generated DESCRIPTION etc, and with good
> > reason. A simple example is the vim-spell-* packages.
> >
> OK. Do you think a generated EAPI is a good idea? I'm curious as to
> how that would be reflected in the filename (as well as your reasons
> ofc.)

I'm suggesting that if EAPI is a variable, there are use cases for being
able to set the variable in ways other than right at the top of the
ebuild. If it isn't a variable then those use cases aren't relevant.

> No: without knowing the EAPI when generating said data. If that needs
> to be known relatively soon in order to generate the rest, extract it
> early. You still only need to load the file from disk once, and you
> don't need to source to get that data, given one simple restriction
> (only declaring it once.)

You can't get the EAPI from the ebuild without knowing what EAPI the
ebuild uses. That's one of the points you're missing.

> >> (I note this is a technical consideration of the implementation,
> >> given as a reason to change a clean API-- with consequences for
> >> workflow.)
> > 
> > No no. It's already an ebuild-visible issue, and there's no way it
> > can't be that doesn't involve imposing restrictions upon every
> > single possible future EAPI.
> >
> The *reason* for the change is about the implementation, and it is not
> necessary.

It's an ebuild issue, not a package manager issue.

> I accept it would make metadata generation quicker, but the
> end-user can already use -metadata-transfer atm and never need to run
> that process. It would save many more cycles if more users did imo

You're confusing the two different types of metadata. Which again shows
that you need to start understanding the metadata process before trying
to discuss design decisions relating to it...

> (optimising early here seems silly tbh, given that paludis now
> requires ruby.)

Eh? Now what're you on about?

> Given that, as a user I see no benefit to my machines that would
> justify the maintenance headache which I know as a coder this will
> result in.

There is no maintenance headache.

> Quite apart from all the changes to supporting tools and workflow,
> it's pushing an implementation-specific datum into a namespace where
> it's neither needed nor useful, apart from to the implementation.

It's an ebuild issue, not a package manager issue.

> >> > Ebuilds are not config files.
> >> >
> >> Indeed not, but they can be parsed as such for simple, core,
> >> metadata.
> > 
> > There is currently no information available from an ebuild that can
> > be parsed by any tool other than bash.
> >
> OK, but restricting EAPI= across the board (in the way that others
> have already asked for) and enforcing it via repoman would mean EAPI
> could easily be extracted.

Except that it's an arbitrary, pointless restriction.

> > And again, you show that you don't understand what's going on. EAPI
> > is only specified once except where developers screw up. The GLEP
> > merely moves the EAPI to being set *before* the metadata is
> > generated, which removes all the restrictions that having EAPI as
> > part of the ebuild's content imposes.
> > 
> Hmm I think you should consider the example that this sub-thread is
> about, and whether an apology would be in order.

Huh?

> Since only declaring it the once /seems/ ok with you, what on Earth
> is so hard about extracting it?

With the current situation, the EAPI has to be known for the EAPI to be
calculated. Adding in a pre-pass layer enforcing new file format
restrictions does not solve the problem we're trying to address.

> I'm sure ruby has sufficient text processing capability if the C++ is
> a bit much for you; I remember there was that long-term bug in
> paludis not being able to deal with whitespace in config files, so
> clearly something's up with your text-processing. Hope that's finally
> fixed now.

Again, huh?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Steve Long]

Ciaran McCreesh wrote:
> On Thu, 20 Dec 2007 00:07:35 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> Do you think a generated EAPI is a good idea? I'm curious as to
>> how that would be reflected in the filename (as well as your reasons
>> ofc.)
> 
> I'm suggesting that if EAPI is a variable, there are use cases for being
> able to set the variable in ways other than right at the top of the
> ebuild. If it isn't a variable then those use cases aren't relevant.
>
Point is that your filename format restricts it in exactly the same manner.
So let's just stick with the use cases which /that/ supports, which can
more easily be supported with the original design and the simple
restriction people keep asking for.

>> No: without knowing the EAPI when generating said data. If that needs
>> to be known relatively soon in order to generate the rest, extract it
>> early. You still only need to load the file from disk once, and you
>> don't need to source to get that data, given one simple restriction
>> (only declaring it once.)
> 
> You can't get the EAPI from the ebuild without knowing what EAPI the
> ebuild uses. That's one of the points you're missing.
>
Wow that doesn't half sound like nonsense. On the one hand you want a
restricted filename suffix, on the other it *has* to be full bash parsing.

An EAPI="blah" at top-level in the file is exactly the same as the suffix in
terms of what can be represented (actually more capable: it also enables eg
prefix EAPIs which I understand was one of the main motivations to extend
the format away from a defined ordering.) If the EAPI introduces a further
eapi function, all well and good; the same datum is still required, whether
kept in the filename or in the ebuild.

According to the original discussion this was always supposed to be a
variable set in the ebuild source:
"We would like to introduce a new ebuild variable named EBUILD_FORMAT,
that tags the ebuild with a specific ebuild API version it provides or
uses."[1]

At that time others made the case for restricting its format in exactly the
same way you have been resisting for the ebuild source, but see as fine for
tacking onto the end of the filename:
"I would also suggest requiring that EAPI can be retrieved by a simple 
line by line parsing without using bash. (This allows for changing the 
parsing system)"[2]

The idea of a different suffix was discussed back then as well:
"portage *should not* ignore those ebuilds.  If the user 
wants to merge something that is a later ebuild api then they have, at 
least portage chucks an exception that the UI can wrap into 'upgrade 
portage'.

With what you're proposing, we instead get bugs about portage missing 
packages."[3]

(That was written when there were no other PMs besides portage3/pkgcore)

http://www.mail-archive.com/gentoo-dev%40lists.gentoo.org/msg03946.html
has a fuller discussion.

> It's an ebuild issue, not a package manager issue.
>
You keep saying that; sure EAPI is visible to ebuild and maintainer (doh)
but the reason you have stated for this change in file naming (which is a
lot more far-reaching than a simple restriction on the format of a
variable) is so that the *PM* doesn't have to source the ebuild to get the
EAPI.

Several people have independently suggested the same solution that would
work fine in the existing framework, which was in fact proposed in 2005:
"Mainly, limiting the syntax has the undesired affect of deviating from 
what users/devs know already; mistakes *will* occur.  QA tools can be 
written, but people are fallable; both in writing a QA tool, and 
abiding by the syntax subset allowed."[3]
I don't think those are really an issue nowadays; devs know to run repoman,
and so do sunrise submitters.

I haven't seen one lucid explanation from you for why it wouldn't work,
beyond ramblings about requiring full bash sourcing capability for what you
yourself envisage as being a static variable, fixed per file.

>> I accept it would make metadata generation quicker, but the
>> end-user can already use -metadata-transfer atm and never need to run
>> that process. It would save many more cycles if more users did imo
> 
> You're confusing the two different types of metadata. Which again shows
> that you need to start understanding the metadata process before trying
> to discuss design decisions relating to it...
>
It doesn't make any practical difference[4]: the computational issue is how
to avoid a source statement via bash from another language.

I note in passing that a metadata cache is available, with no runtime
requirement on the user's part, since it is taken from the rsync'ed data.

>> (optimising early here seems silly tbh, given that paludis now
>> requires ruby.)
> 
> Eh? Now what're you on about?
>
http://bugs.gentoo.org/show_bug.cgi?id=198864

>> Given that, as a user I see no benefit to my machines that would
>> justify the maintenance headache which I know as a coder this will
>> result in.
> 
> There is no maintenance headache.
>
Yeah, keep saying it. That'll make it true..

>> Quite apart from all the changes to supporting tools and workflow,
>> it's pushing an implementation-specific datum into a namespace where
>> it's neither needed nor useful, apart from to the implementation.
> 
> It's an ebuild issue, not a package manager issue.
>
Hmm see above. I note you accept that it requires changes to supporting
tools and workflow.
 
>> >> > Ebuilds are not config files.
>> >> >
>> >> Indeed not, but they can be parsed as such for simple, core,
>> >> metadata.
>> > 
>> > There is currently no information available from an ebuild that can
>> > be parsed by any tool other than bash.
>> >
>> OK, but restricting EAPI= across the board (in the way that others
>> have already asked for) and enforcing it via repoman would mean EAPI
>> could easily be extracted.
> 
> Except that it's an arbitrary, pointless restriction.
>
Er arbitrary, no, since in practise it means exactly the same thing as the
filename suffix (one single string declaration.) Pointless not at all,
since it allows you to avoid calling bash and waiting for it to source,
without an ugly hack. It also keeps the existing work practises that
everyone is used to and doesn't mandate any changes to support tools.

Given that what we currently have actually supports more than the suffix
does, I would class the proposal as pointless restriction, requiring
code-changes for zero benefit to devs and users, while arbitrarily setting
the prefix project back. And let's not pretend that making code changes
across the board will be that easy; regressions are no fun, and nor are new
bugs, especially when they result from changes imposed for no technical
merit.

>> Hmm I think you should consider the example that this sub-thread is
>> about, and whether an apology would be in order.
> 
> Huh?
>
Gee is it really that hard to look back at the example from your colleague
that started this sub-thread? Yet you expect everyone else to keep track of
every delightful comment from you.. *sigh*
 
>> Since only declaring it the once /seems/ ok with you, what on Earth
>> is so hard about extracting it?
> 
> With the current situation, the EAPI has to be known for the EAPI to be
> calculated. Adding in a pre-pass layer enforcing new file format
> restrictions does not solve the problem we're trying to address.
> 
There is no pre-pass layer enforcing restrictions (nice FUD though); repoman
or QA-toolFoo would do the check before the ebuild even got into the tree.
And again, as others pointed out when this was first discussed, and still
others have pointed out on this list, it really isn't that hard to get a
simple EAPI="foo" out of a file, and the restriction is exactly the same
for the maintainer as with your hacked on suffix. The QA check before
committing can trivially enforce the singleton restriction and we can use
EAPI as it was intended with no change to workflow and much less work.


[1] http://www.mail-archive.com/gentoo-dev%40lists.gentoo.org/msg02668.html
[2] http://www.mail-archive.com/gentoo-dev%40lists.gentoo.org/msg03868.html
[3] http://www.mail-archive.com/gentoo-dev%40lists.gentoo.org/msg03873.html
[4] But thanks for the explanation, that really cleared things up. I'll
assume you're talking about metadata generation during depgraph resol'n
then, until you scold me for misunderstanding again. And I note that you
have been disparaging of discussion of bash optimisations in eclass/ebuild
code, yet are falling over yourself to give everyone else a load of work to
speed up what I thought was already the fastest PM known to humanity.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Richard Brown]

On Dec 20, 2007 12:48 PM, Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Ciaran McCreesh wrote:
> > On Thu, 20 Dec 2007 00:07:35 +0000
> > Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> >> (optimising early here seems silly tbh, given that paludis now
> >> requires ruby.)
> >
> > Eh? Now what're you on about?
> >
> http://bugs.gentoo.org/show_bug.cgi?id=198864

Correct, paludis uses dev-ruby/syntax to highlight its ruby examples.

When it's building.

We thought it was worth the performance hit, apparently we were wrong.

/me hangs head in shame, searches for a syntax highlighter written in
cross-platform assembly.

-- 
Richard Brown
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

On Thursday 20 December 2007 13:48:31 Steve Long wrote:
> >> (optimising early here seems silly tbh, given that paludis now
> >> requires ruby.)
> >
> > Eh? Now what're you on about?
>
> http://bugs.gentoo.org/show_bug.cgi?id=198864

So here you're showing that you don't know what a USE flag is?

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

On Thu, Dec 20, 2007 at 02:12:24PM +0100, Bo Ørsted Andresen wrote:
> On Thursday 20 December 2007 13:48:31 Steve Long wrote:
> > >> (optimising early here seems silly tbh, given that paludis now
> > >> requires ruby.)
> > >
> > > Eh? Now what're you on about?
> >
> > http://bugs.gentoo.org/show_bug.cgi?id=198864
> 
> So here you're showing that you don't know what a USE flag is?

It is good he made it crystal clear though. Nobody has to 'guess' now.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 6898 bytes --]

On Thu, 20 Dec 2007 12:48:31 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Point is that your filename format restricts it in exactly the same
> manner. So let's just stick with the use cases which /that/ supports,
> which can more easily be supported with the original design and the
> simple restriction people keep asking for.

Er, the use case is having trivial-as-possible ebuilds for things that
really are purely eclass managed.

> >> No: without knowing the EAPI when generating said data. If that
> >> needs to be known relatively soon in order to generate the rest,
> >> extract it early. You still only need to load the file from disk
> >> once, and you don't need to source to get that data, given one
> >> simple restriction (only declaring it once.)
> > 
> > You can't get the EAPI from the ebuild without knowing what EAPI the
> > ebuild uses. That's one of the points you're missing.
> >
> Wow that doesn't half sound like nonsense.

Unfortunately, it's not nonsense. It's entirely true. If you don't
understand that then you can't contribute anything useful to the
discussion, so kindly stay out of it.

> An EAPI="blah" at top-level in the file is exactly the same as the
> suffix in terms of what can be represented

But not in what can be changed.

> According to the original discussion this was always supposed to be a
> variable set in the ebuild source:

And things moved on. Right back when this first came up several people
pointed out why a variable isn't an optimal solution.

> At that time others made the case for restricting its format in
> exactly the same way you have been resisting for the ebuild source,
> but see as fine for tacking onto the end of the filename:
> "I would also suggest requiring that EAPI can be retrieved by a
> simple line by line parsing without using bash. (This allows for
> changing the parsing system)"[2]

Except that that proposal doesn't work, as we've already established.

> The idea of a different suffix was discussed back then as well:
> "portage *should not* ignore those ebuilds.  If the user 
> wants to merge something that is a later ebuild api then they have,
> at least portage chucks an exception that the UI can wrap into
> 'upgrade portage'.

There are times when the ebuilds have to be ignored.

> With what you're proposing, we instead get bugs about portage missing 
> packages."[3]

Only when absolutely necessary -- and it's only absolutely necessary
when introducing changes such as version suffix extensions that would
result in packages not being usable anyway.

> (That was written when there were no other PMs besides
> portage3/pkgcore)

Learn your history.

> > It's an ebuild issue, not a package manager issue.
> >
> You keep saying that; sure EAPI is visible to ebuild and maintainer
> (doh) but the reason you have stated for this change in file naming
> (which is a lot more far-reaching than a simple restriction on the
> format of a variable) is so that the *PM* doesn't have to source the
> ebuild to get the EAPI.

It's so that the ebuild's EAPI can be extracted. The way things are
currently, there is no way to get an ebuild's EAPI without already
knowing its EAPI.

> > You're confusing the two different types of metadata. Which again
> > shows that you need to start understanding the metadata process
> > before trying to discuss design decisions relating to it...
> >
> It doesn't make any practical difference[4]: the computational issue
> is how to avoid a source statement via bash from another language.
> 
> I note in passing that a metadata cache is available, with no runtime
> requirement on the user's part, since it is taken from the rsync'ed
> data.

And *again* you demonstrate that you don't understand the metadata
process. The metadata cache cannot be generated without already knowing
the ebuild's EAPI, which is part of its metadata.

> >> (optimising early here seems silly tbh, given that paludis now
> >> requires ruby.)
> > 
> > Eh? Now what're you on about?
> >
> http://bugs.gentoo.org/show_bug.cgi?id=198864

Thankyou for demonstrating to everyone that you don't know what a USE
flag is.

> >> >> > Ebuilds are not config files.
> >> >> >
> >> >> Indeed not, but they can be parsed as such for simple, core,
> >> >> metadata.
> >> > 
> >> > There is currently no information available from an ebuild that
> >> > can be parsed by any tool other than bash.
> >> >
> >> OK, but restricting EAPI= across the board (in the way that others
> >> have already asked for) and enforcing it via repoman would mean
> >> EAPI could easily be extracted.
> > 
> > Except that it's an arbitrary, pointless restriction.
> >
> Er arbitrary, no, since in practise it means exactly the same thing
> as the filename suffix (one single string declaration.) Pointless not
> at all, since it allows you to avoid calling bash and waiting for it
> to source, without an ugly hack. It also keeps the existing work
> practises that everyone is used to and doesn't mandate any changes to
> support tools.

...and imposes arbitrary, pointless restrictions upon the format, which
is exactly what EAPI is supposed to prevent.

> >> Hmm I think you should consider the example that this sub-thread is
> >> about, and whether an apology would be in order.
> > 
> > Huh?
> >
> Gee is it really that hard to look back at the example from your
> colleague that started this sub-thread? Yet you expect everyone else
> to keep track of every delightful comment from you.. *sigh*

The problem is, it's rather hard to keep track of what you think you're
going on about when your arguments are based upon a very limited
understanding of what's being discussed.

> >> Since only declaring it the once /seems/ ok with you, what on Earth
> >> is so hard about extracting it?
> > 
> > With the current situation, the EAPI has to be known for the EAPI
> > to be calculated. Adding in a pre-pass layer enforcing new file
> > format restrictions does not solve the problem we're trying to
> > address.
> > 
> There is no pre-pass layer enforcing restrictions (nice FUD though);

No, there's a pre-pass layer which by its existence enforces
restrictions.

> [4] But thanks for the explanation, that really cleared things up.
> I'll assume you're talking about metadata generation during depgraph
> resol'n then, until you scold me for misunderstanding again. And I
> note that you have been disparaging of discussion of bash
> optimisations in eclass/ebuild code, yet are falling over yourself to
> give everyone else a load of work to speed up what I thought was
> already the fastest PM known to humanity.

Uh... It's not a performance issue. And again you show just how badly
you fail to get what's being discussed.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

Ciaran McCreesh wrote:
> On Thu, 20 Dec 2007 12:48:31 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> Point is that your filename format restricts it in exactly the same
>> manner. So let's just stick with the use cases which /that/ supports,
>> which can more easily be supported with the original design and the
>> simple restriction people keep asking for.
> 
> Er, the use case is having trivial-as-possible ebuilds for things that
> really are purely eclass managed.
> 

How is having a line that states EAPI=foo in the ebuild any less trivial
than putting a -foo at the end of the filename?  If anything the latter
is more typing - since the EAPI=foo line would probably be in skel.ebuild...


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

Re: [gentoo-dev] Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

Richard Freeman kirjoitti:
> 
> How is having a line that states EAPI=foo in the ebuild any less trivial
> than putting a -foo at the end of the filename?  If anything the latter
> is more typing - since the EAPI=foo line would probably be in skel.ebuild...
> 

EAPI=foo is already in skel.ebuild but it's commented because EAPI 1
should only be used when there is a need for the new features.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Steve Long]

Ciaran McCreesh wrote:
> On Thu, 20 Dec 2007 12:48:31 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> >> No: without knowing the EAPI when generating said data. If that
>> >> needs to be known relatively soon in order to generate the rest,
>> >> extract it early. You still only need to load the file from disk
>> >> once, and you don't need to source to get that data, given one
>> >> simple restriction (only declaring it once.)
>> > 
>> > You can't get the EAPI from the ebuild without knowing what EAPI the
>> > ebuild uses. That's one of the points you're missing.
>> >
>> Wow that doesn't half sound like nonsense.
> 
> Unfortunately, it's not nonsense. It's entirely true. If you don't
> understand that then you can't contribute anything useful to the
> discussion, so kindly stay out of it.
>
[This (along with your stubborn refusal to ever explain anything) is what I
mean by your manner not inviting discussion.]

The datum you want is in a line in the file, easily extractable without
sourcing. If you don't understand that it provides the same functionality,
kindly go back to Uni and ask them to take your degree back.

>> An EAPI="blah" at top-level in the file is exactly the same as the
>> suffix in terms of what can be represented
> 
> But not in what can be changed.
>
Nonsense: if the file isn't source'able the package manager will know this
due to the EAPI line giving an unknown key, and won't bother doing anything
else with it.

You can put whatever you want in there as long as you have the EAPI
declaration.

>> According to the original discussion this was always supposed to be a
>> variable set in the ebuild source:
> 
> And things moved on. Right back when this first came up several people
> pointed out why a variable isn't an optimal solution.
>
You can't even be bothered to provide a link, let alone any sort of
explanation. You haven't explained at any point why a line in the ebuild is
so unacceptable, yet you keep asserting that it's already been established
that it won't work. Even though that was the design that was originally
agreed upon, back when you were still a Gentoo dev.

>> At that time others made the case for restricting its format in
>> exactly the same way you have been resisting for the ebuild source,
>> but see as fine for tacking onto the end of the filename:
>> "I would also suggest requiring that EAPI can be retrieved by a
>> simple line by line parsing without using bash. (This allows for
>> changing the parsing system)"[2]
> 
> Except that that proposal doesn't work, as we've already established.
>
No you just state it, in other threads too. That's not establishing
anything, and certainly not consensus.

It is trivial to extract one line and gives the information required without
sourcing. In effect, it's stating that the one thing which can't be dynamic
in an ebuild is the EAPI setting, which your proposal requires as well.

>> The idea of a different suffix was discussed back then as well:
>> "portage *should not* ignore those ebuilds.  If the user
>> wants to merge something that is a later ebuild api then they have,
>> at least portage chucks an exception that the UI can wrap into
>> 'upgrade portage'.
> 
> There are times when the ebuilds have to be ignored.
>
Yes and if the EAPI is unsupported the manager can skip it.

>> With what you're proposing, we instead get bugs about portage missing
>> packages."[3]
> 
> Only when absolutely necessary -- and it's only absolutely necessary
> when introducing changes such as version suffix extensions that would
> result in packages not being usable anyway.
>
Yeah kinda like the idea of having an EAPI setting in the ebuild so that the
manager can ignore it if it uses unsupported extensions, or even a
different language.

>> > It's an ebuild issue, not a package manager issue.
>> >
>> You keep saying that; sure EAPI is visible to ebuild and maintainer
>> (doh) but the reason you have stated for this change in file naming
>> (which is a lot more far-reaching than a simple restriction on the
>> format of a variable) is so that the *PM* doesn't have to source the
>> ebuild to get the EAPI.
> 
> It's so that the ebuild's EAPI can be extracted. The way things are
> currently, there is no way to get an ebuild's EAPI without already
> knowing its EAPI.
>
Like I said, it's trivial to extract a line from the ebuild without
sourcing. You know it is, and so does everyone else.

>> > You're confusing the two different types of metadata. Which again
>> > shows that you need to start understanding the metadata process
>> > before trying to discuss design decisions relating to it...
>> >
>> It doesn't make any practical difference[4]: the computational issue
>> is how to avoid a source statement via bash from another language.
>> 
>> I note in passing that a metadata cache is available, with no runtime
>> requirement on the user's part, since it is taken from the rsync'ed
>> data.
> 
> And *again* you demonstrate that you don't understand the metadata
> process. The metadata cache cannot be generated without already knowing
> the ebuild's EAPI, which is part of its metadata.
>
So extract the line and get the value, and stop pretending this is some
mystic art only you and the people who agree with you have the ability to
comprehend. It's coding, and yeah it's tricky sometimes, but it's being run
by a CPU; if you can explain it to the computer you can explain it to
someone else (if you want to; if all you're about is putdowns, ofc,  you
can obfuscate and take 5 mails to get across what could have been done in
1, all the while telling the people who have no choice but to deal with you
that it's all their problem. Asperger's is bad, m'kay?)

>> >> (optimising early here seems silly tbh, given that paludis now
>> >> requires ruby.)
>> > 
>> > Eh? Now what're you on about?
>> >
>> http://bugs.gentoo.org/show_bug.cgi?id=198864
> 
> Thankyou for demonstrating to everyone that you don't know what a USE
> flag is.
>
Eh, no I had thought that the reason people have been complaining about
paludis bloat and forcing make -j0 (512MB of RAM required per make process)
was the dep on ruby. Clearly you can bloat it all on your own.

>> >> > There is currently no information available from an ebuild that
>> >> > can be parsed by any tool other than bash.
>> >> >
>> >> OK, but restricting EAPI= across the board (in the way that others
>> >> have already asked for) and enforcing it via repoman would mean
>> >> EAPI could easily be extracted.
>> > 
>> > Except that it's an arbitrary, pointless restriction.
>> >
>> Er arbitrary, no, since in practise it means exactly the same thing
>> as the filename suffix (one single string declaration.) Pointless not
>> at all, since it allows you to avoid calling bash and waiting for it
>> to source, without an ugly hack. It also keeps the existing work
>> practises that everyone is used to and doesn't mandate any changes to
>> support tools.
> 
> ...and imposes arbitrary, pointless restrictions upon the format, which
> is exactly what EAPI is supposed to prevent.
>
Rubbish: it imposes a restriction on ONE line of the whole thing. And the
restriction on the format of that item, is less than the restrictions
implicit in making it a file suffix.

>> >> Since only declaring it the once /seems/ ok with you, what on Earth
>> >> is so hard about extracting it?
>> > 
>> > With the current situation, the EAPI has to be known for the EAPI
>> > to be calculated. Adding in a pre-pass layer enforcing new file
>> > format restrictions does not solve the problem we're trying to
>> > address.
>> > 
>> There is no pre-pass layer enforcing restrictions (nice FUD though);
> 
> No, there's a pre-pass layer which by its existence enforces
> restrictions.
>
You just said we were adding it with the "file format restrictions" on one
line of the ebuild; I simply pointed out that it doesn't have to be checked
by the package manager. That means the limited restriction (which no-one
minds) enforced by repoman is not "adding in a pre-pass layer enforcing new
file format restriction" as you incorrectly stated.

Honestly it's hard to keep with what you think you're talking about; one
minute things have to be very restricted, the next we have to support use
cases no-one is interested in. You wade into a sub-thread and apparently
forget the code example under discussion, even though it's in the prior
mail, yet insist that everyone else *research* your words; and not only
across threads, no we apparently have to read through your code as well as
your frankly unpleasant words, simply to get an idea of what problem you
think this is solving.

Not conducive to Free software development, not what the Gentoo community is
about (or at least, not the one I enjoy) and certainly not my idea of fun.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 7125 bytes --]

On Sat, 22 Dec 2007 00:59:53 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> >> Wow that doesn't half sound like nonsense.
> > 
> > Unfortunately, it's not nonsense. It's entirely true. If you don't
> > understand that then you can't contribute anything useful to the
> > discussion, so kindly stay out of it.
> >
> [This (along with your stubborn refusal to ever explain anything) is
> what I mean by your manner not inviting discussion.]
> 
> The datum you want is in a line in the file, easily extractable
> without sourcing. If you don't understand that it provides the same
> functionality, kindly go back to Uni and ask them to take your degree
> back.

Except there's absolutely no guarantee that it is, nor that it always
will be.

> >> An EAPI="blah" at top-level in the file is exactly the same as the
> >> suffix in terms of what can be represented
> > 
> > But not in what can be changed.
> >
> Nonsense: if the file isn't source'able the package manager will know
> this due to the EAPI line giving an unknown key, and won't bother
> doing anything else with it.
> 
> You can put whatever you want in there as long as you have the EAPI
> declaration.

Which is what I said: it's different in what can be changed.

> >> According to the original discussion this was always supposed to
> >> be a variable set in the ebuild source:
> > 
> > And things moved on. Right back when this first came up several
> > people pointed out why a variable isn't an optimal solution.
> >
> You can't even be bothered to provide a link, let alone any sort of
> explanation. You haven't explained at any point why a line in the
> ebuild is so unacceptable, yet you keep asserting that it's already
> been established that it won't work. Even though that was the design
> that was originally agreed upon, back when you were still a Gentoo
> dev.

The GLEP explains it all.

> >> At that time others made the case for restricting its format in
> >> exactly the same way you have been resisting for the ebuild source,
> >> but see as fine for tacking onto the end of the filename:
> >> "I would also suggest requiring that EAPI can be retrieved by a
> >> simple line by line parsing without using bash. (This allows for
> >> changing the parsing system)"[2]
> > 
> > Except that that proposal doesn't work, as we've already
> > established.
>
> No you just state it, in other threads too. That's not establishing
> anything, and certainly not consensus.
> 
> It is trivial to extract one line and gives the information required
> without sourcing. In effect, it's stating that the one thing which
> can't be dynamic in an ebuild is the EAPI setting, which your
> proposal requires as well.

No, it's stating that EAPI has to be static, in a particular format, in
a particular place, set in a particular way. Only the first of those is
a reasonable requirement.

> >> The idea of a different suffix was discussed back then as well:
> >> "portage *should not* ignore those ebuilds.  If the user
> >> wants to merge something that is a later ebuild api then they have,
> >> at least portage chucks an exception that the UI can wrap into
> >> 'upgrade portage'.
> > 
> > There are times when the ebuilds have to be ignored.
> >
> Yes and if the EAPI is unsupported the manager can skip it.

Again, you miss the point: at the package manager, there's a distinction
between knowing that there's an ebuild that isn't supported because of
its EAPI and not even being sure what exactly a particular ebuild is to
the extend that you don't know its CATEGORY/PN/PV. Only being able to
handle the first of these is insufficient.

> > It's so that the ebuild's EAPI can be extracted. The way things are
> > currently, there is no way to get an ebuild's EAPI without already
> > knowing its EAPI.
> >
> Like I said, it's trivial to extract a line from the ebuild without
> sourcing. You know it is, and so does everyone else.

Note *the way things are currently*. If you think this is untrue,
provide an algorithm that will correctly give the EAPI of any current
or future ebuild given that ebuild's filename (hint: you can't).

> > And *again* you demonstrate that you don't understand the metadata
> > process. The metadata cache cannot be generated without already
> > knowing the ebuild's EAPI, which is part of its metadata.
> >
> So extract the line and get the value, and stop pretending this is
> some mystic art only you and the people who agree with you have the
> ability to comprehend. It's coding, and yeah it's tricky sometimes,
> but it's being run by a CPU; if you can explain it to the computer
> you can explain it to someone else (if you want to; if all you're
> about is putdowns, ofc,  you can obfuscate and take 5 mails to get
> across what could have been done in 1, all the while telling the
> people who have no choice but to deal with you that it's all their
> problem. Asperger's is bad, m'kay?)

With the way things are currently you *can't* extract the line and get
the value, because there's no guarantee on what the line is or what the
meaning of global scope statements are. For example, what's the EAPI
for the following ebuild?

# Copyright blah

inherit vim-spell using language="en"


> >> >> (optimising early here seems silly tbh, given that paludis now
> >> >> requires ruby.)
> >> > 
> >> > Eh? Now what're you on about?
> >> >
> >> http://bugs.gentoo.org/show_bug.cgi?id=198864
> > 
> > Thankyou for demonstrating to everyone that you don't know what a
> > USE flag is.
> >
> Eh, no I had thought that the reason people have been complaining
> about paludis bloat and forcing make -j0 (512MB of RAM required per
> make process) was the dep on ruby. Clearly you can bloat it all on
> your own.

Amusingly enough... It's due to the (optional) dep upon Python, not
Ruby. But hey, carry on not having a clue what you're on about.

> > ...and imposes arbitrary, pointless restrictions upon the format,
> > which is exactly what EAPI is supposed to prevent.
> >
> Rubbish: it imposes a restriction on ONE line of the whole thing. And
> the restriction on the format of that item, is less than the
> restrictions implicit in making it a file suffix.

Nnnnope. The suffix approach doesn't prevent future changes that use
new suffixes.

> > No, there's a pre-pass layer which by its existence enforces
> > restrictions.
> >
> You just said we were adding it with the "file format restrictions"
> on one line of the ebuild; I simply pointed out that it doesn't have
> to be checked by the package manager. That means the limited
> restriction (which no-one minds) enforced by repoman is not "adding
> in a pre-pass layer enforcing new file format restriction" as you
> incorrectly stated.

The package manager has to check its input, since repoman may not have
been run, and it has to have the pre-pass layer to be able to generate
EAPI to be able to generate metadata. So yes, it is entirely necessary
with your proposal.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Sat, 22 Dec 2007 00:59:53 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>>> It's so that the ebuild's EAPI can be extracted. The way things are
>>> currently, there is no way to get an ebuild's EAPI without already
>>> knowing its EAPI.
>>>
>> Like I said, it's trivial to extract a line from the ebuild without
>> sourcing. You know it is, and so does everyone else.
> 
> Note *the way things are currently*. If you think this is untrue,
> provide an algorithm that will correctly give the EAPI of any current
> or future ebuild given that ebuild's filename (hint: you can't).

Simple.
Whatever you'd like to have in the suffix, we can put it on the first line of
the ebuild.
Just go and get it, and that's the EAPI.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

On Sat, 22 Dec 2007 16:55:50 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > Note *the way things are currently*. If you think this is untrue,
> > provide an algorithm that will correctly give the EAPI of any
> > current or future ebuild given that ebuild's filename (hint: you
> > can't).
> 
> Simple.
> Whatever you'd like to have in the suffix, we can put it on the first
> line of the ebuild.
> Just go and get it, and that's the EAPI.

Your algorithm:

Does not work for existing ebuilds that have implicit EAPI 0.

Does not work for existing ebuilds that have explicit EAPI.

Does not work for future ebuilds.

That's nought for three.

-- 
Ciaran McCreesh
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Sat, 22 Dec 2007 16:55:50 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>>> Note *the way things are currently*. If you think this is untrue,
>>> provide an algorithm that will correctly give the EAPI of any
>>> current or future ebuild given that ebuild's filename (hint: you
>>> can't).
>> Simple.
>> Whatever you'd like to have in the suffix, we can put it on the first
>> line of the ebuild.
>> Just go and get it, and that's the EAPI.
> 
> Your algorithm:
> 
> Does not work for existing ebuilds that have implicit EAPI 0.

That's obvious. If no suffix, just treat it as EAPI 0.
I thought I don't need to say this explicitly.

> 
> Does not work for existing ebuilds that have explicit EAPI.

Even better, since we don't need suffix in the first place. Just define it in
ebuild.

> 
> Does not work for future ebuilds.

If defined in file does not work, then define in file name doesn't either.
They are interchangeable.
All could be get before sourcing.
I know you'd say people will use all syntaxes to define. But how many are
there? EAPI=1, EAPI="1" these are the two ways currently used in tree.
A simple qgrep can show that.
Two steps can guarantee you get the value
1. strip "
2. get the value


-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

On Sat, Dec 22, 2007 at 06:01:04PM +0800, Zhang Le wrote:
> > 
> > Your algorithm:
> > 
> > Does not work for existing ebuilds that have implicit EAPI 0.
> 
> That's obvious. If no suffix, just treat it as EAPI 0.
> I thought I don't need to say this explicitly.

'# Copyright 1999-2007 Gentoo Foundation'

Is that an EAPI? of course it is not, are you going to hardcode every
possible ebuild header in your stupid _hack_ ?

> > 
> > Does not work for existing ebuilds that have explicit EAPI.
> 
> Even better, since we don't need suffix in the first place. Just define it in
> ebuild.

What?

> > 
> > Does not work for future ebuilds.
> 
> If defined in file does not work, then define in file name doesn't either.
> They are interchangeable.

No, they are not.

> All could be get before sourcing.
> I know you'd say people will use all syntaxes to define. But how many are
> there? EAPI=1, EAPI="1" these are the two ways currently used in tree.
> A simple qgrep can show that.
> Two steps can guarantee you get the value
> 1. strip "
> 2. get the value

And then you are stuck FOREVER into defining EAPI as a variable.

You clearly haven't read anything on this thread. I suggest you go and
do so before making a fool of yourself again. Please.

Please guys, keep in mind that the fact that some of you understand what
a filename is and are able to provide simple commands that extract a
particular line from a file does not entitle you with the knowdledge
required to contribute something useful to this discussion.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 3279 bytes --]

Fernando J. Pereda wrote:
> On Sat, Dec 22, 2007 at 06:01:04PM +0800, Zhang Le wrote:
>> All could be get before sourcing.
>> I know you'd say people will use all syntaxes to define. But how many are
>> there? EAPI=1, EAPI="1" these are the two ways currently used in tree.
>> A simple qgrep can show that.
>> Two steps can guarantee you get the value
>> 1. strip "
>> 2. get the value
> 
> And then you are stuck FOREVER into defining EAPI as a variable.
> 

And with the proposed GLEP you are stuck FOREVER into defining EAPI as
part of the filename.  What's the difference?

> You clearly haven't read anything on this thread. I suggest you go and
> do so before making a fool of yourself again. Please.

I doubt that they have failed to see that this reply has been made
before.  Very little has been posted in the last day on this thread that
hasn't already been posted the day before.  The issue isn't that people
are too dumb to realize the limitations of putting "EAPI=foo" in their
ebuilds - the issue is that many don't believe that this is much of a
limitation.  However, nobody wants to stop replying because they're
probably concerned that their ignoring this thread will be accepted as
evidence of acceptance of the proposal.

> 
> Please guys, keep in mind that the fact that some of you understand what
> a filename is and are able to provide simple commands that extract a
> particular line from a file does not entitle you with the knowdledge
> required to contribute something useful to this discussion.

This really isn't helpful.  It is essentially an ad-hominum argument.
The fundamental issue is that there is a disagreement over whether
leaving things as they are currently is a major problem.  If others
don't have the knowledge necessary to contribute something useful then
take the time to educate them - don't tell them to just be quiet.  The
number of replies in this thread obviously indicates that we're not
talking about 1-2 people who aren't quite sure what is going on and 200
people that clearly agree with the merits of this proposal.  If so many
people can't see the value in this GLEP then perhaps it isn't adequately
explained?

As I see it, the only real advantage of changing filenames vs a variable
with formatting requirements (thus allowing it to be scanned without
sourcing the ebuild) seems to be that it will prevent current package
managers from breaking when they source an ebuild due to new global
functions.  The only other objection I've seen raised is that the
variable approach limits your future options regarding content - but I
don't see that as being really any worse than limiting the filename.
Either way its a few bytes in a particular spot on the disk - why is one
better than the other?

I'm actually warming up to this proposal a little, but those in favor of
it would do well to address concerns and discuss them with those who
raise them (possibly by irc/off-list-email as needed) and not just tell
them to be quiet about it.  The goal isn't to bash everybody in to
submission within 2 days so that the GLEP can get approved - the goal is
to gather input so that the GLEP can be as good as possible when it is
approved.  You don't need to completely agree with your critics to at
least consider their objections.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Richard Freeman wrote:
> Fernando J. Pereda wrote:
>> On Sat, Dec 22, 2007 at 06:01:04PM +0800, Zhang Le wrote:
>>> All could be get before sourcing.
>>> I know you'd say people will use all syntaxes to define. But how many are
>>> there? EAPI=1, EAPI="1" these are the two ways currently used in tree.
>>> A simple qgrep can show that.
>>> Two steps can guarantee you get the value
>>> 1. strip "
>>> 2. get the value
>> And then you are stuck FOREVER into defining EAPI as a variable.
>>
> 
> And with the proposed GLEP you are stuck FOREVER into defining EAPI as
> part of the filename.  What's the difference?

Ditto.

> 
>> You clearly haven't read anything on this thread. I suggest you go and
>> do so before making a fool of yourself again. Please.

If I haven't read previous posts, then I would not participate in this
discussion in the first place. I have read a lot and feel like I should say
something so that my previous reading are not totally wasted.


-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

On Sat, 22 Dec 2007 10:12:51 -0500
Richard Freeman <rich@thefreemanclan.net> wrote:
> > And then you are stuck FOREVER into defining EAPI as a variable.
> 
> And with the proposed GLEP you are stuck FOREVER into defining EAPI as
> part of the filename.  What's the difference?

No you aren't. That is the difference.
-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Fernando J. Pereda wrote:
> On Sat, Dec 22, 2007 at 06:01:04PM +0800, Zhang Le wrote:
>>> Your algorithm:
>>>
>>> Does not work for existing ebuilds that have implicit EAPI 0.
>> That's obvious. If no suffix, just treat it as EAPI 0.
>> I thought I don't need to say this explicitly.
> 
> '# Copyright 1999-2007 Gentoo Foundation'
> 
> Is that an EAPI? of course it is not, are you going to hardcode every
> possible ebuild header in your stupid _hack_ ?

We are doing this in almost every file format we are using.
ELF(exacutable and linkable format)
JPEG
GIF
...
If this is stupidity, then we are all stupid.

>>> Does not work for future ebuilds.
>> If defined in file does not work, then define in file name doesn't either.
>> They are interchangeable.
> 
> No, they are not.

Why not?
Please always add a reason, which is helpful to the discussion.
Thanks!

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

On Thu, Dec 20, 2007 at 12:07:35AM +0000, Steve Long wrote:
> Since only declaring it the once /seems/ ok with you, what on Earth is so
> hard about extracting it? I'm sure ruby has sufficient text processing
> capability if the C++ is a bit much for you; I remember there was that
> long-term bug in paludis not being able to deal with whitespace in config
> files, so clearly something's up with your text-processing. Hope that's
> finally fixed now.

Hahahahahahaha you just made my day. As usual, your input is close to
worthless.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> 
> You need to understand the metadata generation process to understand why
> the package manger has to assume a particular EAPI when generating the
> metadata. 

There are many people watching this thread all over the world I think.
Not all of them understand the process.
And you are keeping scolding people for not understanding the process.

So, why not introduce the process a little bit?


-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

On Fri, 21 Dec 2007 02:27:27 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > You need to understand the metadata generation process to
> > understand why the package manger has to assume a particular EAPI
> > when generating the metadata. 
> 
> There are many people watching this thread all over the world I think.
> Not all of them understand the process.
> And you are keeping scolding people for not understanding the process.
> 
> So, why not introduce the process a little bit?

Because the process is decidedly non-trivial, and anyone who hasn't
spent a considerable time studying it and understanding it isn't going
to be able to contribute anything useful anyway.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]

On Fri, 21 Dec 2007 10:49:04 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> > Because the process is decidedly non-trivial, and anyone who hasn't
> > spent a considerable time studying it and understanding it isn't
> > going to be able to contribute anything useful anyway.
> 
> But human beings are able to understand it, right?

Sure, if they think about it carefully.

> Is there any documentation about it?

Nope. Not beyond the code, anyway... Although the code is clear enough
that anyone who's going to be able to understand the explanation can
understand the code.

> If not, why not consider write one?

Because it's a waste of time.

> It should not appear as a black box, and effectively prevent normal
> gentoo users and developers from contributing to decisions which may
> have a great impact on their distro.

The GLEP doesn't have a great impact. It's a purely internal matter
that shouldn't be visible to users at all and should be very easy for
developers to follow once implemented.

Really, the idea that anyone can contribute and express a useful opinion
is all very well, but it's terribly naive. Do you expect to be asked to
give your opinion upon the proportion of zinc mixed in with the
aluminium in your car? Do you tell your doctor how much thimerosal you
want in your medicine?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 10:49:04 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
> 
>> It should not appear as a black box, and effectively prevent normal
>> gentoo users and developers from contributing to decisions which may
>> have a great impact on their distro.
> 
> The GLEP doesn't have a great impact. It's a purely internal matter
> that shouldn't be visible to users at all and should be very easy for
> developers to follow once implemented.
> 
> Really, the idea that anyone can contribute and express a useful opinion
> is all very well, but it's terribly naive. Do you expect to be asked to
> give your opinion upon the proportion of zinc mixed in with the
> aluminium in your car? Do you tell your doctor how much thimerosal you
> want in your medicine?

Those are not analogous to open source software development, IMO.
People can't decide on those things. But they can and should be able to
influence on decision we are making here.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> And again, you show that you don't understand what's going on. EAPI is
> only specified once except where developers screw up. The GLEP merely
> moves the EAPI to being set *before* the metadata is generated, which
> removes all the restrictions that having EAPI as part of the ebuild's
> content imposes.

So, you are saying if developers screw up, then the EAPI could be specified
twice, namely in file name and in file content.
But why should we tolerate that?

And as I have said before, I don't see why having EAPI as part of the ebuild's
content has any restrictions.
You can extrace the definition from file content no matter how it is defined
using whatever way you like.


-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

On Fri, 21 Dec 2007 02:45:48 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > And again, you show that you don't understand what's going on. EAPI
> > is only specified once except where developers screw up. The GLEP
> > merely moves the EAPI to being set *before* the metadata is
> > generated, which removes all the restrictions that having EAPI as
> > part of the ebuild's content imposes.
> 
> So, you are saying if developers screw up, then the EAPI could be
> specified twice, namely in file name and in file content.
> But why should we tolerate that?

Uh, you don't. You just specify how the package manager handles it
because there's no room for undefined behaviour here.

> And as I have said before, I don't see why having EAPI as part of the
> ebuild's content has any restrictions.
> You can extrace the definition from file content no matter how it is
> defined using whatever way you like.

Ok. What's the EAPI for the following ebuild that's written in an EAPI
that hasn't been published yet? And how would I extract it?

# Copyright blah blah

import vim-spell using language="en"

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Ciaran McCreesh wrote:
> Ok. What's the EAPI for the following ebuild that's written in an EAPI
> that hasn't been published yet? And how would I extract it?
> 
> # Copyright blah blah
> 
> import vim-spell using language="en"

If isn't published it doesn't exist in the main tree...

lu


-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

On Fri, 21 Dec 2007 03:14:12 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > Ok. What's the EAPI for the following ebuild that's written in an
> > EAPI that hasn't been published yet? And how would I extract it?
> > 
> > # Copyright blah blah
> > 
> > import vim-spell using language="en"
> 
> If isn't published it doesn't exist in the main tree...

You miss my point. If a package manager encounters the above, how does
it determine the EAPI?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

On Fri, 21 Dec 2007 10:52:04 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Fri, 21 Dec 2007 03:14:12 +0100
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >> Ciaran McCreesh wrote:
> >>> Ok. What's the EAPI for the following ebuild that's written in an
> >>> EAPI that hasn't been published yet? And how would I extract it?
> >>>
> >>> # Copyright blah blah
> >>>
> >>> import vim-spell using language="en"
> >> If isn't published it doesn't exist in the main tree...
> > 
> > You miss my point. If a package manager encounters the above, how
> > does it determine the EAPI?
> 
> As long as there is an agreement between the PM and ebuild, you can
> get what you want no matter how it is defined.

So how does one get the EAPI in the above example? Bear in mind that
package managers can only use what's been agreed upon at the time they
were released, not what might be agreed upon later -- and yet they need
to be able to extract the EAPI from anything agreed upon later.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 10:52:04 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>>> On Fri, 21 Dec 2007 03:14:12 +0100
>>> Luca Barbato <lu_zero@gentoo.org> wrote:
>>>> Ciaran McCreesh wrote:
>>>>> Ok. What's the EAPI for the following ebuild that's written in an
>>>>> EAPI that hasn't been published yet? And how would I extract it?
>>>>>
>>>>> # Copyright blah blah
>>>>>
>>>>> import vim-spell using language="en"
>>>> If isn't published it doesn't exist in the main tree...
>>> You miss my point. If a package manager encounters the above, how
>>> does it determine the EAPI?
>> As long as there is an agreement between the PM and ebuild, you can
>> get what you want no matter how it is defined.
> 
> So how does one get the EAPI in the above example?

That's the problem about the agreement between PM and ebuild.

If this is agreed upon
>>>>> import vim-spell using language="en"
You should be able to get it.

If not, then blame the ebuild writer. There is no problem with the agreement.

> Bear in mind that
> package managers can only use what's been agreed upon at the time they
> were released, not what might be agreed upon later -- and yet they need
> to be able to extract the EAPI from anything agreed upon later.

Exactly my point.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

On Fri, 21 Dec 2007 11:51:03 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> That's the problem about the agreement between PM and ebuild.
> 
> If this is agreed upon
> >>>>> import vim-spell using language="en"
> You should be able to get it.
> 
> If not, then blame the ebuild writer. There is no problem with the
> agreement.

Uh... It's not agreed upon currently. It may be agreed upon in the
future, but that's no good for current package managers. Current
package managers have to be able to deal with future agreements,
without limiting those future agreements to not being able to make
changes like the above example.

> > Bear in mind that
> > package managers can only use what's been agreed upon at the time
> > they were released, not what might be agreed upon later -- and yet
> > they need to be able to extract the EAPI from anything agreed upon
> > later.
> 
> Exactly my point.

So we all agree that suffixes are the solution, since they solve this
problem and in-ebuild-content restrictions don't. Good.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 11:51:03 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>> That's the problem about the agreement between PM and ebuild.
>>
>> If this is agreed upon
>>>>>>> import vim-spell using language="en"
>> You should be able to get it.
>>
>> If not, then blame the ebuild writer. There is no problem with the
>> agreement.
> 
> Uh... It's not agreed upon currently. 

It is not about whether it is agreed upon currently.
As long as there is an agreement in any given point of time, it is OK.
Such as, put your EAPI definition on the first line of your ebuild, like
EAPI="value"

>>> Bear in mind that
>>> package managers can only use what's been agreed upon at the time
>>> they were released, not what might be agreed upon later -- and yet
>>> they need to be able to extract the EAPI from anything agreed upon
>>> later.
>> Exactly my point.
> 
> So we all agree that suffixes are the solution, since they solve this
> problem and in-ebuild-content restrictions don't. Good.

No, quite contrary.
See above.


-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

On Fri, 21 Dec 2007 12:20:31 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> It is not about whether it is agreed upon currently.

It is. That's the entire point of the whole discussion.

> As long as there is an agreement in any given point of time, it is OK.
> Such as, put your EAPI definition on the first line of your ebuild,
> like EAPI="value"

No good for package managers written before the agreement.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
>> As long as there is an agreement in any given point of time, it is OK.
>> Such as, put your EAPI definition on the first line of your ebuild,
>> like EAPI="value"
> 
> No good for package managers written before the agreement.

Why not force user to upgrade their PM?
After all, upgrading is part of our normal life.

Now I will try read portage to understand how the metadata generation process
works and try to make a doc of it.
So before that, I will probably be not so responsive.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

On Sat, 22 Dec 2007 16:49:10 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> >> As long as there is an agreement in any given point of time, it is
> >> OK. Such as, put your EAPI definition on the first line of your
> >> ebuild, like EAPI="value"
> > 
> > No good for package managers written before the agreement.
> 
> Why not force user to upgrade their PM?

That's a) exactly what we're trying to avoid with EAPIs, b) no good
because there isn't a sane way of forcing a package manager upgrade and
c) another one of those "wait a year until we can use anything" things.

-- 
Ciaran McCreesh
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Sat, 22 Dec 2007 16:49:10 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>>>> As long as there is an agreement in any given point of time, it is
>>>> OK. Such as, put your EAPI definition on the first line of your
>>>> ebuild, like EAPI="value"
>>> No good for package managers written before the agreement.
>> Why not force user to upgrade their PM?
> 
> That's a) exactly what we're trying to avoid with EAPIs, b) no good
> because there isn't a sane way of forcing a package manager upgrade and
> c) another one of those "wait a year until we can use anything" things.

People have to upgrade even if we adopt the suffix approach, as like I just said.
We don't actually need to force people upgrade their PM, if they need new
version of software whose ebuild is in new EAPI, they will want to upgrade
their PM themselves, either way.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Ciaran McCreesh wrote:
> On Sat, 22 Dec 2007 16:49:10 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>>>> As long as there is an agreement in any given point of time, it is
>>>> OK. Such as, put your EAPI definition on the first line of your
>>>> ebuild, like EAPI="value"
>>> No good for package managers written before the agreement.
>> Why not force user to upgrade their PM?
> 
> That's a) exactly what we're trying to avoid with EAPIs,

I guess it was giving a smooth upgrade path

> b) no good because there isn't a sane way of forcing a package manager upgrade and

Say why?

> c) another one of those "wait a year until we can use anything" things.

Or spend 6 months discussing something that may or may not be accepted
because lacks enough documentation to be decided on...

lu - and 2008 is just next week..

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

On Fri, 21 Dec 2007 03:44:20 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Fri, 21 Dec 2007 03:14:12 +0100
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >> Ciaran McCreesh wrote:
> >>> Ok. What's the EAPI for the following ebuild that's written in an
> >>> EAPI that hasn't been published yet? And how would I extract it?
> >>>
> >>> # Copyright blah blah
> >>>
> >>> import vim-spell using language="en"
> >> If isn't published it doesn't exist in the main tree...
> > 
> > You miss my point. If a package manager encounters the above, how
> > does it determine the EAPI?
> > 
> 
> from :
> 
> - a default set by the repository, if we chose to use that
> - a default set by itself
> - by not understanding it thus failing in a brutal (hard error) or
> gentle (ignore the file, warn) way.

None of those solve the original problem.

> I'm looking for alternatives.

From the filename suffix. Simple!

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]

Ciaran McCreesh wrote:
> 
> Ok. What's the EAPI for the following ebuild that's written in an EAPI
> that hasn't been published yet? And how would I extract it?
> 
> # Copyright blah blah
> 
> import vim-spell using language="en"
> 

Counterexample.  How do you determine the eapi for the following file,
which uses an EAPI that is yet unpublished - but which specifies that
the EAPI NOT go in the filename:  foo-1.2.ebuild

Obviously if you go down one road, and then intentionally change things
to go down another then old stuff won't work.  Any package manager that
depends on having the EAPI in the filename won't work if a decision is
later made to remove the EAPI from the filename.

Making a decision to put the EAPI in the filename for all time doesn't
seem any less restricting than making a decision to put EAPI=1 or
EAPI="1" in the ebuild for all time.  And the latter is a whole lot less
messy as far as I can see.

So far the only objection I've seen to putting EAPI in the ebuild is
that at some point in the future we might want to do it differently.
Well, that is nice, but the same issue would apply to putting it in the
filename - we could want to change that someday too.  And if we put it
in the filename why would we want to put it in a function or whatever
inside the ebuild as well?  Wouldn't that just be redundant.

Sure, by not putting it in the filename we restrict ourselves a little
from changing things later.  However, if we do put in the filename we
seem to already have a mass of folks who would want to change it RIGHT
NOW.

And if the whole point of this is to allow massive changes to ebuild
format - why not wait until a need for such a change exists before
instituting it.  Why not defer this GLEP until it has some benefit and
not just pain associated with it?

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]

On Fri, 21 Dec 2007 08:29:34 -0500
Richard Freeman <rich@thefreemanclan.net> wrote:
> Ciaran McCreesh wrote:
> > Ok. What's the EAPI for the following ebuild that's written in an
> > EAPI that hasn't been published yet? And how would I extract it?
> > 
> > # Copyright blah blah
> > 
> > import vim-spell using language="en"
> > 
> 
> Counterexample.  How do you determine the eapi for the following file,
> which uses an EAPI that is yet unpublished - but which specifies that
> the EAPI NOT go in the filename:  foo-1.2.ebuild

You're back to using a pre-source EAPI to extract the real EAPI then,
which is the way things are currently -- and it means that any EAPI
that specifies what you describe has to be sufficiently close to EAPI 0
that package managers that only understand EAPI 0 will work with it.

> Making a decision to put the EAPI in the filename for all time doesn't
> seem any less restricting than making a decision to put EAPI=1 or
> EAPI="1" in the ebuild for all time.  And the latter is a whole lot
> less messy as far as I can see.

It's an awful lot less restrictive.

> So far the only objection I've seen to putting EAPI in the ebuild is
> that at some point in the future we might want to do it differently.
> Well, that is nice, but the same issue would apply to putting it in
> the filename - we could want to change that someday too.  And if we
> put it in the filename why would we want to put it in a function or
> whatever inside the ebuild as well?  Wouldn't that just be redundant.

If the GLEP is followed, you *can* change the filename to absolutely
anything that isn't either *.ebuild or *.ebuild-(any-previous-eapi), or
various silly things like metadata.xml and files.

> And if the whole point of this is to allow massive changes to ebuild
> format - why not wait until a need for such a change exists before
> instituting it.  Why not defer this GLEP until it has some benefit and
> not just pain associated with it?

There is plenty of need, as you would know had you either read the GLEP
or paid attention on this list recently.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Joe Peterson]

Steve Long wrote:
> Ciaran McCreesh wrote:
>> There is no duplication of information, nor redundancy.
>>
> So what were the QA checks you mentioned to confirm that the same EAPI is
> set in both the filename and the ebuild, for-- if not integrity of
> duplicated data?

+1

>> Really. It's a heck of a lot cleaner in the filename suffix.
>>
> Nah, it's an awful hack and you know it. It has nothing to do with package
> naming and is unnecessary exposure of internal data.

Yes!  Thank you, Steve!

						-Joe
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

> Steve Long wrote:
>> Ciaran McCreesh wrote:
>>> Really. It's a heck of a lot cleaner in the filename suffix.
>>>
>> Nah, it's an awful hack and you know it. It has nothing to do with package
>> naming and is unnecessary exposure of internal data.
> 

Forgive me if I missed this in the previous 500 emails, but I still
don't quite understand why you can't just put EAPI="whatever" in the
ebuild in a fixed place and leave it at that.

The biggest objection to this that I've seen is that somebody might want
to set it dynamically, which would be impossible to handle without
sourcing it.  However, you can't possibly put dynamic content in the
filename (PLEASE let's not try!), so it sounds like we're stuck with
fixed EAPI settings either way.  So, why not just put it in the ebuild?

If I were designing a binary file format I'd probably have a header with
a version number in a fixed position, and a length-of-header field in a
fixed position - then you could extend it all you want and old readers
could either safely ignore it or at least know where the fields it
understands are.

Now, obviously we don't want to make every dev do anything like that on
a manually-edited file.  However, we could simply specify a simple
format for the EAPI variable, and then have QA software (repoman/etc)
make sure that it is in the correct format.  Then it could be safely
parsed with a regexp or whatever.

Am I missing something?

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

On Wed, 19 Dec 2007 18:59:47 -0500
Richard Freeman <rich@thefreemanclan.net> wrote:
> Am I missing something?

Yes. You're missing all the explanations that have already been given
about why it's impossible to parse ebuilds using anything other than
bash.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

Ciaran McCreesh wrote:
> On Wed, 19 Dec 2007 18:59:47 -0500
> Richard Freeman <rich@thefreemanclan.net> wrote:
>> Am I missing something?
> 
> Yes. You're missing all the explanations that have already been given
> about why it's impossible to parse ebuilds using anything other than
> bash.
> 

If the EAPI can be parsed from a filename without using bash, why
couldn't it be parsed from a line in the ebuild contents without using
bash?

An inelegant solution (but possibly more elegant than using filenames)
might be to put the EAPI on the first line of the ebuild, with nothing
else on that line.  Then a simple head -n 1 <file> retrieves the EAPI.
Certainly not pretty - but perhaps nicer than putting the EAPI in the
filename itself.  And I don't see how it is any less flexible than
putting it in the filename - if nothing else it would allow you a larger
character set without making command-line work painful.

However, I still don't see how a regexp wouldn't work - if you made the
policy that all ebuilds must have a line that says:
EAPI="<something>" - exactly.  No spaces, quotes mandatory, etc.  That
can't be any less painful on devs than putting the EAPI in the filename,
and it could be checked for by repoman/etc.  Or, if package managers are
willing to do a little more work we could allow a little whitespace and
make things easier on devs.

Issues with not using bash to parse the EAPI value would come into play
mainly in situations where putting the EAPI in the filename wouldn't
work either.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]

On Wed, 19 Dec 2007 20:28:55 -0500
Richard Freeman <rich@thefreemanclan.net> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 19 Dec 2007 18:59:47 -0500
> > Richard Freeman <rich@thefreemanclan.net> wrote:
> >> Am I missing something?
> > 
> > Yes. You're missing all the explanations that have already been
> > given about why it's impossible to parse ebuilds using anything
> > other than bash.
> 
> If the EAPI can be parsed from a filename without using bash, why
> couldn't it be parsed from a line in the ebuild contents without using
> bash?

Because a) a future EAPI might want to change EAPI into a function
rather than a variable, b) there are a zillion ways of setting a
variable in bash and people already use all of them and c) introducing
new weird format requirements is silly.

> An inelegant solution (but possibly more elegant than using filenames)
> might be to put the EAPI on the first line of the ebuild, with nothing
> else on that line.  Then a simple head -n 1 <file> retrieves the EAPI.
> Certainly not pretty - but perhaps nicer than putting the EAPI in the
> filename itself.  And I don't see how it is any less flexible than
> putting it in the filename

It imposes format restrictions upon the ebuild. Currently there aren't
any such format restrictions. EAPIs are designed to *remove* this kind
of inflexibility, not add to it.

> if nothing else it would allow you a
> larger character set without making command-line work painful.

A large character set for EAPI is silly. Anyone naming an EAPI that
isn't a-zA-Z0-9-+_ should be taken out and shot.

> However, I still don't see how a regexp wouldn't work - if you made
> the policy that all ebuilds must have a line that says:
> EAPI="<something>" - exactly.  No spaces, quotes mandatory, etc.  That
> can't be any less painful on devs than putting the EAPI in the
> filename, and it could be checked for by repoman/etc.  Or, if package
> managers are willing to do a little more work we could allow a little
> whitespace and make things easier on devs.

And then EAPI 3 comes along and says "Set EAPI using the eapi
function". Oops, we're back to the original issue all over again.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> posted
20071220035400.7ef9c32b@blueyonder.co.uk, excerpted below, on  Thu, 20 Dec
2007 03:54:00 +0000:

> On Wed, 19 Dec 2007 20:28:55 -0500
> Richard Freeman <rich@thefreemanclan.net> wrote:
>> Ciaran McCreesh wrote:
>> > On Wed, 19 Dec 2007 18:59:47 -0500
>> > Richard Freeman <rich@thefreemanclan.net> wrote:
>> >> Am I missing something?
>> > 
>> > Yes. You're missing all the explanations that have already been given
>> > about why it's impossible to parse ebuilds using anything other than
>> > bash.
>> 
>> If the EAPI can be parsed from a filename without using bash, why
>> couldn't it be parsed from a line in the ebuild contents without using
>> bash?
> 
> Because a) a future EAPI might want to change EAPI into a function
> rather than a variable, b) there are a zillion ways of setting a
> variable in bash and people already use all of them and c) introducing
> new weird format requirements is silly.

So you're proposing putting the function into the filename?

As he stated, the only credible reason (so far given) bash must be used 
to parse EAPI is if it's dynamic, say a function, and that won't work so 
well in a filename either.  Thus, putting EAPI in the filename pretty 
much eliminates the possibility of it being a function, and we're back to 
the original question, instead of a GLEP allowing it in the filename, why 
not a GLEP specifying the format of that single variable in the file 
contents well enough to parse without bash?

Or, if you are proposing that the pre-source EAPI in the filename could 
be superseded by a function, if that is specifically allowed by the (pre-
source) EAPI defined in the filename, then we are back to what I 
suggested earlier, that you specifically said wasn't necessary (and I 
basically deferred to your judgement), that the pre-source and post-
source EAPI be specifically allowed to be different.

Either the EAPI must be static, so it can be set in the filename, or it 
can be set dynamically, in which case allowing the pre-source and post-
source EAPI to be different actually makes sense.

That said, I do agree that putting it in the filename seems safer, as if 
the PM doesn't understand that EAPI, it can stop right at the filename, 
and doesn't have to worry about parsing the contents of the file itself 
at all, period.  That's safer than having to parse it at least minimally, 
to find out at least the EAPI, before deciding whether it can go 
further.  Thus, regardless of the function thing, I support EAPI in the 
filename as simply safer.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]

On Thu, 20 Dec 2007 09:43:59 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> > Because a) a future EAPI might want to change EAPI into a function
> > rather than a variable, b) there are a zillion ways of setting a
> > variable in bash and people already use all of them and c)
> > introducing new weird format requirements is silly.
> 
> So you're proposing putting the function into the filename?

No, I'm saying that the data goes into the filename.

> As he stated, the only credible reason (so far given) bash must be
> used to parse EAPI is if it's dynamic, say a function, and that won't
> work so well in a filename either. 

No no no. Bash is the only thing that can parse bash. Ebuilds are bash.

> Thus, putting EAPI in the filename pretty much eliminates the
> possibility of it being a function, and we're back to the original
> question, instead of a GLEP allowing it in the filename, why not a
> GLEP specifying the format of that single variable in the file
> contents well enough to parse without bash?

Because that would be introducing a new, non-extensible, inflexible
requirement upon the content of ebuilds, and the goal of EAPI is to
avoid doing exactly that.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

Ciaran McCreesh wrote:
> Because that would be introducing a new, non-extensible, inflexible
> requirement upon the content of ebuilds, and the goal of EAPI is to
> avoid doing exactly that.
> 

If you're putting all this metadata in the filename, I'm not sure how
you can distinguish between the filename and the content regarding
flexibility.  If anything I'd rather have more flexibility in filenames
and less in content.  For example, cat/pkgname/version could be a whole
lot more flexible if they were just a string and didn't have to be
parsed out of the concatenated fields in the filename.  Mind you, I'm
not proposing this, but it seems like putting yet another concatenated
field in the filename is only going to make the filenames that much more
complicated.

Unless you're going to make ebuilds semi-machine-built objects like xml
files it is going to be hard to make them completely flexible without
having package managers with a bazillion cases in them for parsing the
files.  That will naturally limit support for lots of EAPIs.

I do agree with your goals - it just seems like there HAS to be a better
way of doing it than putting something at the end of the filename.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Thu, 20 Dec 2007 09:43:59 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>>> Because a) a future EAPI might want to change EAPI into a function
>>> rather than a variable, b) there are a zillion ways of setting a
>>> variable in bash and people already use all of them and c)
>>> introducing new weird format requirements is silly.
>> So you're proposing putting the function into the filename?
> 
> No, I'm saying that the data goes into the filename.

then why not let it go into the file content?
if data goes into file content, then function is not needed
you are contradicting with yourself here.

> 
>> As he stated, the only credible reason (so far given) bash must be
>> used to parse EAPI is if it's dynamic, say a function, and that won't
>> work so well in a filename either. 
> 
> No no no. Bash is the only thing that can parse bash. Ebuilds are bash.

Getting the first line of a file using whatever language is just a piece of cake.
And I don't see why setting a rule on the syntax of EAPI definition is so silly.
How many ways to define a variable in bash can you think of?
Is it that hard to come up with a way to normalized the definition?
Just like charset code normalization, e.g. from UTF-8 to utf8?

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

Ciaran McCreesh wrote:
> Because a) a future EAPI might want to change EAPI into a function
> rather than a variable, 

Why?  It couldn't be dynamic - not if you're going to put it in the
filename as well.  And why have it in two places?  If you are going to
put the EAPI in the filename, why put it inside the ebuild as well?  We
don't do that with version numbers or package names.

> b) there are a zillion ways of setting a
> variable in bash and people already use all of them and c) introducing
> new weird format requirements is silly.

But this GLEP is already proposing a format requirement.  It is just
putting it in the filename instead of in the ebuild contents.  It isn't
like you could just put anything in the filename anywhere you want and
the package manager will be able to understand it.  If devs are going to
have to get correct "-1" at the end of the filename, why couldn't they
also get right "EAPI=1" inside the file?


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 4101 bytes --]

Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

On Thu, 20 Dec 2007 08:56:01 -0500
Richard Freeman <rich@thefreemanclan.net> wrote:
> Ciaran McCreesh wrote:
> > Because a) a future EAPI might want to change EAPI into a function
> > rather than a variable, 
> 
> Why?  It couldn't be dynamic - not if you're going to put it in the
> filename as well.  And why have it in two places?  If you are going to
> put the EAPI in the filename, why put it inside the ebuild as well?
> We don't do that with version numbers or package names.

eapi 3

Is considered by some to look nicer than

EAPI="3"

> > b) there are a zillion ways of setting a
> > variable in bash and people already use all of them and c)
> > introducing new weird format requirements is silly.
> 
> But this GLEP is already proposing a format requirement.  It is just
> putting it in the filename instead of in the ebuild contents.  It
> isn't like you could just put anything in the filename anywhere you
> want and the package manager will be able to understand it.  If devs
> are going to have to get correct "-1" at the end of the filename, why
> couldn't they also get right "EAPI=1" inside the file?

Because in the future we might want to have something other than
setting EAPIs by EAPI=1.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ulrich Mueller]

>>>>> On Tue, 18 Dec 2007, Ciaran McCreesh wrote:

> | Possibility to extend the behaviour of inherit and add new global
> | scope functions (as a result of not sourcing ebuilds with
> | unsupported EAPI).

It seems to me that this will inconvenience the users, in order to
solve a technical problem of the package manager.

Is this really the right way to go?

>> Making the file extension variable by adding "-<EAPI>" to it would,
>> in my opinion, make the portage tree a bit less clean and not as
>> elegant.

+1

>> Wouldn't software (like editors determining file type by looking at
>> what is after the ".") also need to be reworked to recognize a
>> variable string after "-" at the end?

> Yep, but that's not very difficult. And as a side effect, editors
> could then provide EAPI aware highlighting.

They can also do this if EAPI is set within the file.

Ulrich
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

On Tue, 18 Dec 2007 08:17:49 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Tue, 18 Dec 2007, Ciaran McCreesh wrote:
> > | Possibility to extend the behaviour of inherit and add new global
> > | scope functions (as a result of not sourcing ebuilds with
> > | unsupported EAPI).
> 
> It seems to me that this will inconvenience the users, in order to
> solve a technical problem of the package manager.
> 
> Is this really the right way to go?

Well, users shouldn't really be doing anything with .ebuild files... Or
if by users you mean developers, I'd say it's considerably less
inconvenient than having to remember arbitrary syntax restrictions...

> >> Wouldn't software (like editors determining file type by looking at
> >> what is after the ".") also need to be reworked to recognize a
> >> variable string after "-" at the end?
> 
> > Yep, but that's not very difficult. And as a side effect, editors
> > could then provide EAPI aware highlighting.
> 
> They can also do this if EAPI is set within the file.

It's extremely tricky to do correctly... With Vim it'd only work when
opening an existing file with the variable already there. Picking it up
as it's added would require insane CursorHold hackery (which also slows
down Vim quite a bit).

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Thomas de Grenier de Latour]

On 2007/12/18, Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> Well, users shouldn't really be doing anything with .ebuild files...

As a user, i often end reading part of some ebuilds to get a clue about
what the generic "foo" USE flag does in a particular package ("qgrep -A3
-B2 -Nx '\<foo\>' cat/pkg-ver" or alike).

> Or if by users you mean developers, I'd say it's considerably less
> inconvenient than having to remember arbitrary syntax restrictions...

"EAPI=foo must come first" is only one restriction, not several.
It's really easy enough to remember, and devs are more or less about to
conform to it anyway (since EAPI must come prior to "inherits", and
it's in skel.ebuild, etc.).  It's also easy for package managers to
remind it as soon a dev tries to do anything with an offending ebuild
he has just written.  

So please don't make it sound overly complicated when it's not.

You call my proposal a "nasty hack", but seriously, GLEP55's way of
putting one particular metadata in the file name rather than the file
contents whereas it's not discriminating for atoms (the reason you need
to forbid "foo-1.ebuild-blah" and "foo-1.ebuild-booh" existing in the
same dir) is at least as ugly (well, at least it's debatable).
 
And yes, you can answer that there are already such rules in
application, like "foo-1-r0.ebuild" not being allowed together with
"foo-1.ebuild", but my answer would be that's it's not a reason to make
things worst.  In my ideal world, there shouldn't exists several
equal versions with different syntaxes(-r0 would not exists, _p would
be less than _p0, etc.), and a versionned atom should only correspond to
one single possible file name. 

-- 
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Joe Peterson]

Ulrich Mueller wrote:
> It seems to me that this will inconvenience the users, in order to
> solve a technical problem of the package manager.

Absolutely, +1.  This does indeed sound like a technical issue; how
would requiring a dev to manually mirror the EAPI in the filename
extension provide any benefit over caching it behind the scenes (using
the Manifest file or similar mechanism)?

					-Joe
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

On Tue, Dec 18, 2007 at 06:57:33AM -0700, Joe Peterson wrote:
> Ulrich Mueller wrote:
> > It seems to me that this will inconvenience the users, in order to
> > solve a technical problem of the package manager.
> 
> Absolutely, +1.  This does indeed sound like a technical issue; how
> would requiring a dev to manually mirror the EAPI in the filename
> extension provide any benefit over caching it behind the scenes (using
> the Manifest file or similar mechanism)?

You are yet to show what kind of inconvenience to the users this
proposal will cause.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ulrich Mueller]

>>>>> On Tue, 18 Dec 2007, Fernando J Pereda wrote:

>> > It seems to me that this will inconvenience the users, in order to
>> > solve a technical problem of the package manager.
>> 
>> Absolutely, +1.  This does indeed sound like a technical issue; how
>> would requiring a dev to manually mirror the EAPI in the filename
>> extension provide any benefit over caching it behind the scenes (using
>> the Manifest file or similar mechanism)?

> You are yet to show what kind of inconvenience to the users this
> proposal will cause.

One example was mentioned in this thread before: You cannot use
"find -name '*.ebuild'" anymore.

And as we have now learned that EAPI strings are not limited to digits
(see ciaranm's message) and may even contain blanks (see grobian's
message), we would have ebuilds with very strange filenames.

Ulrich
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Santiago M. Mola]

On Dec 18, 2007 6:37 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Tue, 18 Dec 2007, Fernando J Pereda wrote:
>
> >> > It seems to me that this will inconvenience the users, in order to
> >> > solve a technical problem of the package manager.
> >>
> >> Absolutely, +1.  This does indeed sound like a technical issue; how
> >> would requiring a dev to manually mirror the EAPI in the filename
> >> extension provide any benefit over caching it behind the scenes (using
> >> the Manifest file or similar mechanism)?
>
> > You are yet to show what kind of inconvenience to the users this
> > proposal will cause.
>
> One example was mentioned in this thread before: You cannot use
> "find -name '*.ebuild'" anymore.
>

So people could use a bit more elaborated expression to find them.
Things like this shouldn't be a reason for not applying
EAPI/GLEPs/PM-behaviour changes. If this GLEP is approved, it would be
fine to publish a quick guide of recipes to migrate scripts which rely
on the old naming convention and that should be enough.

IMO, keeping us away from improvements to Gentoo because they break
backwards compatibility with third party scripts is a no-go. Of
course, this kind of changes can't happen once a month, but they can
happen from time to time.

Regards,
Santiago

-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Joe Peterson]

Santiago M. Mola wrote:
>> One example was mentioned in this thread before: You cannot use
>> "find -name '*.ebuild'" anymore.
>>
> 
> So people could use a bit more elaborated expression to find them.
> Things like this shouldn't be a reason for not applying
> EAPI/GLEPs/PM-behaviour changes. If this GLEP is approved, it would be
> fine to publish a quick guide of recipes to migrate scripts which rely
> on the old naming convention and that should be enough.
> 
> IMO, keeping us away from improvements to Gentoo because they break
> backwards compatibility with third party scripts is a no-go. Of
> course, this kind of changes can't happen once a month, but they can
> happen from time to time.

I don't think this is about strictly maintaining backwards
compatability.  You are right that we should not let this impede
progress.  My objection is that the proposed scheme does not appear to
make the system more elegant, but rather it creates complexity,
potential errors (mismatches in representions of EAPI), and introduces a
rather unorthodox and complicated file extension pattern.

I also do not see why there are not other more elegant, transparent, and
automatic ways to determine EAPI without sourcing.  I put forth an idea,
and I understand the objections to it, but I'm just brainstorming, and
there *must* be other ways that retain portage's elegance and simplicity.

					-Joe
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Wulf C. Krueger]

[-- Attachment #1: Type: text/plain, Size: 2775 bytes --]

On Tuesday, 18. December 2007 19:20:58 Joe Peterson wrote:
> I also do not see why there are not other more elegant, transparent,
> and automatic ways to determine EAPI without sourcing.  

How much easier can it be? The extension scheme is simple and would do the 
job nicely. 

> brainstorming, and there *must* be other ways that retain portage's
> elegance and simplicity.

A job done well and efficiently in a simple way *is* elegant in my book. 
Not that elegance matters much in the context of this discussion anyway. 

Nor is this about Portage, Paludis, pkgcore or any other package manager - 
this is one way to ease the transition from the current mode of 
operations (CMO) to future modes of operations (FMO) which currently has 
to be slow for compatibility. 

In the CMO, we have to wait for one *year* in the worst case to fully use 
new features. One year - that's above half the lifespan of the average 
Gentoo dev, measured from his evolvement from the bowls of the user pool 
to his rise into the Elysian Fields of retired devs.

In the proposed FMO we could proceed at a faster pace. Sure, we shouldn't 
create EAPIs like ebuilds but if a PM doesn't support an EAPI, it will 
know the moment it reads the filename and can simply ignore it. Finally, 
we could boldly go where no Gentoo dev has gone before - or at least not 
in time. ;-)

(Yes, I'm ignoring the other motivations for the moment.)

I don't really get all these arguments about this proposal being 
inconvenient for users - most of our users don't ever touch any ebuild 
directly. And if they do, they shouldn't have much problem reading a 
filename; after all they've managed to install Gentoo. ;->

Yes, I, too, hate it when some change breaks my precious scripts. I moan a 
bit in my study, complain to my wife about how bad the world is and then 
go on and *fix* my scripts. Really, it's not that hard. And if it is 
there are helpful people all around - in the forums, on the mailing 
lists, in our IRC channels. 

Of course, we can keep discussing 

- the merits or demerits of regular expression matching with respect 
to "ebuild.*", "ebuild-[a-Z0-9]*$" or whatever else comes to mind 
open-endly (sic!), 

- we can can discuss funny filenames as well because we all know how 
mighty important an ebuild's filename to the average user is compared to 
the minor issues like just getting his software installed,

- how to find ebuilds, ignoring the fact that most of our users don't 
really look for *ebuilds* but for *applications* which they find using 
emerge -s, inquisitio -<something>, eix, kuroo or whatever else floats 
their boats.

I just don't think these three roads really lead anywhere.

-- 
Best regards, Wulf

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Daniel Pielmeier]

2007/12/18, Joe Peterson <lavajoe@gentoo.org>:
> Santiago M. Mola wrote:
> >> One example was mentioned in this thread before: You cannot use
> >> "find -name '*.ebuild'" anymore.
> >>
> >
> > So people could use a bit more elaborated expression to find them.
> > Things like this shouldn't be a reason for not applying
> > EAPI/GLEPs/PM-behaviour changes. If this GLEP is approved, it would be
> > fine to publish a quick guide of recipes to migrate scripts which rely
> > on the old naming convention and that should be enough.
> >
> > IMO, keeping us away from improvements to Gentoo because they break
> > backwards compatibility with third party scripts is a no-go. Of
> > course, this kind of changes can't happen once a month, but they can
> > happen from time to time.
>
> I don't think this is about strictly maintaining backwards
> compatability.  You are right that we should not let this impede
> progress.  My objection is that the proposed scheme does not appear to
> make the system more elegant, but rather it creates complexity,
> potential errors (mismatches in representions of EAPI), and introduces a
> rather unorthodox and complicated file extension pattern.
>
> I also do not see why there are not other more elegant, transparent, and
> automatic ways to determine EAPI without sourcing.  I put forth an idea,
> and I understand the objections to it, but I'm just brainstorming, and
> there *must* be other ways that retain portage's elegance and simplicity.
>
>                                         -Joe
> --
> gentoo-dev@gentoo.org mailing list
>
>

Just another brainstorming attempt. Is it possible to use one single
file per eapi which lists all ebuilds using a specific eapi like
package.eapi-name and is stored in the profiles. Or even one single
file which lists the ebuild and its eapi.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

On Tue, Dec 18, 2007 at 06:37:11PM +0100, Ulrich Mueller wrote:
> >>>>> On Tue, 18 Dec 2007, Fernando J Pereda wrote:
> 
> >> > It seems to me that this will inconvenience the users, in order to
> >> > solve a technical problem of the package manager.
> >> 
> >> Absolutely, +1.  This does indeed sound like a technical issue; how
> >> would requiring a dev to manually mirror the EAPI in the filename
> >> extension provide any benefit over caching it behind the scenes (using
> >> the Manifest file or similar mechanism)?
> 
> > You are yet to show what kind of inconvenience to the users this
> > proposal will cause.
> 
> One example was mentioned in this thread before: You cannot use
> "find -name '*.ebuild'" anymore.

Yeah, and you cannot use 'give-me-my-ebuilds' to list them all... people
will have to improve their tools to work with EAPI-suffixed ebuilds.

> And as we have now learned that EAPI strings are not limited to digits
> (see ciaranm's message) and may even contain blanks (see grobian's
> message), we would have ebuilds with very strange filenames.

What's the problem with this?

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

"Fernando J. Pereda" <ferdy@gentoo.org> posted
20071218175632.GC4423@ferdyx.org, excerpted below, on  Tue, 18 Dec 2007
18:56:32 +0100:

>> And as we have now learned that EAPI strings are not limited to digits
>> (see ciaranm's message) and may even contain blanks (see grobian's
>> message), we would have ebuilds with very strange filenames.
> 
> What's the problem with this?

'app-shells/bash-3.2_p17-r1.ebuild-prefix 1' (note the space) anyone?

How about when we have a dozen or so EAPIs active, several of which apply 
to a specific ebuild?

'app-shells/bash-3.2_p17-r1.ebuild-prefix 1 2 foo zork bar baz fa querty 
3 8 4' (and that example uses no odd chars beyond the EAPI component 
space separator)?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

On Tue, Dec 18, 2007 at 07:45:44PM +0000, Duncan wrote:
> "Fernando J. Pereda" <ferdy@gentoo.org> posted
> 20071218175632.GC4423@ferdyx.org, excerpted below, on  Tue, 18 Dec 2007
> 18:56:32 +0100:
> 
> >> And as we have now learned that EAPI strings are not limited to digits
> >> (see ciaranm's message) and may even contain blanks (see grobian's
> >> message), we would have ebuilds with very strange filenames.
> > 
> > What's the problem with this?
> 
> 'app-shells/bash-3.2_p17-r1.ebuild-prefix 1' (note the space) anyone?

I know what filenames with spaces mean, thank you very much.

> How about when we have a dozen or so EAPIs active, several of which apply 
> to a specific ebuild?
> 
> 'app-shells/bash-3.2_p17-r1.ebuild-prefix 1 2 foo zork bar baz fa querty 
> 3 8 4' (and that example uses no odd chars beyond the EAPI component 
> space separator)?

This is talking about something not covered by this GLEP.... so what is
your point?

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Fernando J. Pereda wrote:
> On Tue, Dec 18, 2007 at 07:45:44PM +0000, Duncan wrote:
>> "Fernando J. Pereda" <ferdy@gentoo.org> posted
>> 20071218175632.GC4423@ferdyx.org, excerpted below, on  Tue, 18 Dec 2007
>> 18:56:32 +0100:
>>
>>>> And as we have now learned that EAPI strings are not limited to digits
>>>> (see ciaranm's message) and may even contain blanks (see grobian's
>>>> message), we would have ebuilds with very strange filenames.
>>> What's the problem with this?
>> 'app-shells/bash-3.2_p17-r1.ebuild-prefix 1' (note the space) anyone?
> 
> I know what filenames with spaces mean, thank you very much.
> 
>> How about when we have a dozen or so EAPIs active, several of which apply 
>> to a specific ebuild?
>>
>> 'app-shells/bash-3.2_p17-r1.ebuild-prefix 1 2 foo zork bar baz fa querty 
>> 3 8 4' (and that example uses no odd chars beyond the EAPI component 
>> space separator)?
> 
> This is talking about something not covered by this GLEP.... so what is
> your point?
> 

I think the glep should try to address this concern...

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Piotr Jaroszyński]

On Wednesday 19 of December 2007 15:27:07 Luca Barbato wrote:
> Fernando J. Pereda wrote:
> > On Tue, Dec 18, 2007 at 07:45:44PM +0000, Duncan wrote:
> >> 'app-shells/bash-3.2_p17-r1.ebuild-prefix 1 2 foo zork bar baz fa querty
> >> 3 8 4' (and that example uses no odd chars beyond the EAPI component
> >> space separator)?
> >
> > This is talking about something not covered by this GLEP.... so what is
> > your point?
>
> I think the glep should try to address this concern...

Mixing EAPIs can't work. Strange chars shouldn't be allowed for obvious 
reasons, [A-Za-z0-9+_-] would be fine by me.

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Piotr Jaroszyński wrote:
> Mixing EAPIs can't work.

Why? I'm afraid that before proposing that we could go back thinking
about which is the usage of EAPI.

Is the a concise and clear text about it already?

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 285 bytes --]

On Wed, Dec 19, 2007 at 04:17:21PM +0100, Luca Barbato wrote:
> Piotr Jaroszyński wrote:
> > Mixing EAPIs can't work.
> 
> Why?

Because EAPIs can define colliding features.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Jim Ramsay]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

"Fernando J. Pereda" <ferdy@gentoo.org> wrote:
> On Wed, Dec 19, 2007 at 04:17:21PM +0100, Luca Barbato wrote:
> > Piotr Jaroszyński wrote:
> > > Mixing EAPIs can't work.
> > 
> > Why?
> 
> Because EAPIs can define colliding features.

The sense I've gotten from this discussion so far is that if you want
features from two EAPIs you know *can* be combined without collisions,
you should define a third EAPI that is a superset of the other 2.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

On Wed, Dec 19, 2007 at 11:03:54AM -0500, Jim Ramsay wrote:
> "Fernando J. Pereda" <ferdy@gentoo.org> wrote:
> > On Wed, Dec 19, 2007 at 04:17:21PM +0100, Luca Barbato wrote:
> > > Piotr Jaroszyński wrote:
> > > > Mixing EAPIs can't work.
> > > 
> > > Why?
> > 
> > Because EAPIs can define colliding features.
> 
> The sense I've gotten from this discussion so far is that if you want
> features from two EAPIs you know *can* be combined without collisions,
> you should define a third EAPI that is a superset of the other 2.

*nod* But that is different from arbitrary mixing them, which is what
originated this subthread.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

"Fernando J. Pereda" <ferdy@gentoo.org> posted
20071219165019.GB4601@ferdyx.org, excerpted below, on  Wed, 19 Dec 2007
17:50:19 +0100:

> On Wed, Dec 19, 2007 at 11:03:54AM -0500, Jim Ramsay wrote:
>> 
>> The sense I've gotten from this discussion so far is that if you want
>> features from two EAPIs you know *can* be combined without collisions,
>> you should define a third EAPI that is a superset of the other 2.
> 
> *nod* But that is different from arbitrary mixing them, which is what
> originated this subthread.

Quoting CiaranM from a different subthread, defining EAPI:

> A cat/pkg-ver has exactly one EAPI. That EAPI belongs to the
> cat/pkg-ver as a whole, and is static across that cat/pkg-ver.

Now, we already had someone mention using two together, prefix (which 
seems to have been defined as an EAPI for the purposes of this 
discussion, I don't deal with it so haven't the foggiest about it, 
personally) and EAPI-1.  If that portion of Ciaran's definition quoted 
above stands, that usage would be defined as illegal, thus anything using 
it "broken".

The work-around as Jim mentions above would be defining a third EAPI 
combining as a superset the other two.  One could then create ebuilds 
using that third EAPI.  Of course, until at least one of the available 
package managers supports that third EAPI, ebuilds created to use it 
wouldn't be of much use, and until portage, being the official Gentoo PM, 
supported it, said ebuilds could not be placed in the Gentoo-x86 tree.

The question, then, is whether anyone, particularly those working with 
PMs other than paludis (Ciaran being the lead on it so presumably his 
EAPI definition works for it), disagrees with that portion of Ciaran's 
EAPI definition.  I've seen no such direct disagreement so far, with the 
presumed exception of the person mentioning already combining two 
(without creating a third out of them) in prefix, of course.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Piotr Jaroszyński]

On Tuesday 18 of December 2007 20:45:44 Duncan wrote:
> How about when we have a dozen or so EAPIs active, several of which apply
> to a specific ebuild?

Where is this idea of mixing EAPIs coming from? It really doesn't make much 
sense.

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

Piotr Jaroszyński <peper@gentoo.org> posted
200712182111.20754.peper@gentoo.org, excerpted below, on  Tue, 18 Dec 2007
21:11:20 +0100:

> On Tuesday 18 of December 2007 20:45:44 Duncan wrote:
>> How about when we have a dozen or so EAPIs active, several of which
>> apply to a specific ebuild?
> 
> Where is this idea of mixing EAPIs coming from? It really doesn't make
> much sense.

If EAPI is defined as a particular set of features and rules as grouped 
together under a specific EAPI label (Ciaran's general definition), and 
is specifically not ordered, as is the case, thus allowing, potentially, 
multiple EAPIs to evolve in parallel (Grobian's message), as the upthread 
argues is possible, even likely...

And if a particular ebuild uses features from a non-conflicting super-set 
of several such EAPIs (Ulrich's message) ...

Then said ebuild under this GLEP would need labeled with "the lot of 
'em."  The message to which I replied (Fernando's) asked what's the 
problem with that, so I provided an example.  Now it /was/ extreme -- one 
would hope it wouldn't ever get quite /that/ bad, but given the context, 
I guess I agree with Ulrich' comment -- that the resulting filenames 
could indeed end up rather strange looking.  It's certainly something I 
hadn't thought of until he connected the dots.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]

On Tue, 18 Dec 2007 23:50:22 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> Piotr Jaroszyński <peper@gentoo.org> posted
> 200712182111.20754.peper@gentoo.org, excerpted below, on  Tue, 18 Dec
> 2007 21:11:20 +0100:
> > On Tuesday 18 of December 2007 20:45:44 Duncan wrote:
> >> How about when we have a dozen or so EAPIs active, several of which
> >> apply to a specific ebuild?
> > 
> > Where is this idea of mixing EAPIs coming from? It really doesn't
> > make much sense.
> 
> If EAPI is defined as a particular set of features and rules as
> grouped together under a specific EAPI label (Ciaran's general
> definition), and is specifically not ordered, as is the case, thus
> allowing, potentially, multiple EAPIs to evolve in parallel
> (Grobian's message), as the upthread argues is possible, even
> likely...

But you can't mix features arbitrarily.

> And if a particular ebuild uses features from a non-conflicting
> super-set of several such EAPIs (Ulrich's message) ...

Then there should be an EAPI defined that permits all of those features.

Functionality would only be removed from EAPIs for specific reasons:

* Conflicts with new features (think *DEPEND vs DEPENDENCIES). In which
case, you can't mix features between EAPIs anyway.

* Deprecating old nasty features. In which case, you shouldn't be
using said features anyway.

* Massively different EAPIs. In which case you reaaaallly can't mix
EAPIs.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> posted
20071219000653.401ba9ba@blueyonder.co.uk, excerpted below, on  Wed, 19 Dec
2007 00:06:53 +0000:

>> And if a particular ebuild uses features from a non-conflicting
>> super-set of several such EAPIs (Ulrich's message) ...
> 
> Then there should be an EAPI defined that permits all of those features.
> 
> Functionality would only be removed from EAPIs for specific reasons:
> 
> * Conflicts with new features (think *DEPEND vs DEPENDENCIES). In which
> case, you can't mix features between EAPIs anyway.
> 
> * Deprecating old nasty features. In which case, you shouldn't be using
> said features anyway.
> 
> * Massively different EAPIs. In which case you reaaaallly can't mix
> EAPIs.

I thought it worthwhile when I saw the question asked, but given your 
experience in the matter and the lack of anyone from the other PMs saying 
otherwise, I'll take your word for it.  Thanks.  (Of course I can't/don't 
speak for the original question poster.)

(BTW, saw the http://obsethryl.eu interview.  While I'm probably part of 
the "noise", someone with the demonstrated tenacity to follow thru as you 
do... every comment gets a reply... that deserves and gets a lot of 
respect, in my book.  Thanks /for/ that follow-thru.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Piotr Jaroszyński]

On Tuesday 18 of December 2007 18:37:11 Ulrich Mueller wrote:
> One example was mentioned in this thread before: You cannot use
> "find -name '*.ebuild'" anymore.

This should really be one of the last things to consider.

> And as we have now learned that EAPI strings are not limited to digits
> (see ciaranm's message) and may even contain blanks (see grobian's
> message), we would have ebuilds with very strange filenames.

I think you misunderstood grobian's mail, which is "how we do it in prefix" 
anyway.

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ulrich Mueller]

>>>>> On Tue, 18 Dec 2007, Piotr Jaroszynski wrote:

>> One example was mentioned in this thread before: You cannot use
>> "find -name '*.ebuild'" anymore.

> This should really be one of the last things to consider.

On the contrary. If you want to force users to change their habits,
then it should be one of the first things to consider if this is
really necessary.

>> And as we have now learned that EAPI strings are not limited to digits
>> (see ciaranm's message) and may even contain blanks (see grobian's
>> message), we would have ebuilds with very strange filenames.

> I think you misunderstood grobian's mail,

There was nothing that could be misunderstood. The sentence in
question was:
| As a result I now have EAPI="prefix 1" ebuilds.

> which is "how we do it in prefix" anyway.

Where is documented what characters are allowed in an EAPI string?

Ulrich
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Piotr Jaroszyński]

On Tuesday 18 of December 2007 19:51:54 Ulrich Mueller wrote:
> > This should really be one of the last things to consider.
>
> On the contrary. If you want to force users to change their habits,
> then it should be one of the first things to consider if this is
> really necessary.

Simple users don't play with ebuilds, others are well capable of adjusting 
their "habits".

> >> And as we have now learned that EAPI strings are not limited to digits
> >> (see ciaranm's message) and may even contain blanks (see grobian's
> >> message), we would have ebuilds with very strange filenames.
> >
> > I think you misunderstood grobian's mail,
>
> There was nothing that could be misunderstood. The sentence in
>
> question was:
> | As a result I now have EAPI="prefix 1" ebuilds.

Where he meant a combination of "prefix" and "1" EAPIs, which is prefix 
specific.

> Where is documented what characters are allowed in an EAPI string?

Nowhere that I am aware of, but [A-Za-z0-9-_] sounds reasonable to me.

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Fabian Groffen]

On 18-12-2007 21:08:54 +0100, Piotr Jaroszyński wrote:
> > >> And as we have now learned that EAPI strings are not limited to digits
> > >> (see ciaranm's message) and may even contain blanks (see grobian's
> > >> message), we would have ebuilds with very strange filenames.
> > >
> > > I think you misunderstood grobian's mail,
> >
> > There was nothing that could be misunderstood. The sentence in
> >
> > question was:
> > | As a result I now have EAPI="prefix 1" ebuilds.
> 
> Where he meant a combination of "prefix" and "1" EAPIs, which is prefix 
> specific.

prefix is neither "mainstream", nor "standard".  The way I solved "it"
currently hence is just a temporal workaround.  I brought up the example
simply because I'm strugling myself with how EAPI will eventually allow
for "Prefix" to enter the main tree (or not), if ever.

Currently the combination in EAPI serves me pretty well, and hence yes,
if this GLEP gets accepted I'll have to find another way to achieve the
same as it's not going to work well in the extention.


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Jeroen Roovers]

On Mon, 17 Dec 2007 23:20:01 +0100
Piotr Jaroszyński <peper@gentoo.org> wrote:

> Hello,
> 
> attaching the GLEP.

How does this chord with eclasses that set EAPI, instead of ebuilds?
Last I read was that EAPI-set-by-eclass was close to being ratified.


Kind regards,
     JeR
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

On Tue, 18 Dec 2007 05:41:45 +0100
Jeroen Roovers <jer@gentoo.org> wrote:
> How does this chord with eclasses that set EAPI, instead of ebuilds?
> Last I read was that EAPI-set-by-eclass was close to being ratified.

Read where? So far as I'm aware, everyone's been saying "don't set EAPI
in an eclass".

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Jeroen Roovers]

On Tue, 18 Dec 2007 04:46:35 +0000
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Tue, 18 Dec 2007 05:41:45 +0100
> Jeroen Roovers <jer@gentoo.org> wrote:
> > How does this chord with eclasses that set EAPI, instead of ebuilds?
> > Last I read was that EAPI-set-by-eclass was close to being ratified.
> 
> Read where? So far as I'm aware, everyone's been saying "don't set
> EAPI in an eclass".

On this mailing list, in the "EAPI placement" thread.


     JeR
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Jeroen Roovers]

On Tue, 18 Dec 2007 06:27:02 +0100
Jeroen Roovers <jer@gentoo.org> wrote:

> On this mailing list, in the "EAPI placement" thread.

OK, it would seem that discussion has now died in favour of
forbidding eclasses setting EAPI altogether. But now, if
pkg-5.ebuild-zillion doesn't set an EAPI variable, how will the eclass
know it? Perhaps the GLEP should explain that the package manager is 
required to set the EAPI variable in the environment.


     JeR
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

Piotr Jaroszyński <peper@gentoo.org> posted
200712172320.01988.peper@gentoo.org, excerpted below, on  Mon, 17 Dec 2007
23:20:01 +0100:

> Let's call the EAPI included in the ebuild filename the pre-source EAPI,
> and the EAPI set inside the ebuild the post-source EAPI. Given these
> two, the final EAPI used by the ebuild can be established by following
> these steps:
> 
> * If the pre-source EAPI is not set it defaults to 0. 
> * If the pre-source EAPI is not recognised it is returned
>   immediately.
> * If the post-source EAPI is not set, it defaults to the
>   pre-source EAPI.
> * post-source EAPI is returned.
> 
> The above process should be only used to generate the metadata cache.
> Should the pre-source EAPI be unsupported the cache entry cannot be
> generated.
> 
> Ebuilds with unsupported EAPIs are masked.
> 
> QA tools should consider it an error for both EAPIs to be set explicitly
> to different values. Package managers may warn, but must use the
> post-source EAPI in such cases.


Up until that last quoted paragraph above, I had an entirely different 
idea of where this was headed.  It's either incredibly stupid, or it's 
great outside-the-box thinking that just might be useful.  Might as well 
ask or I'll never know. =8^)

Put directly, what is stopping us from actually allowing DIFFERENT pre-
source and post-source EAPI values?

Here's the thinking.  In the various PM discussions I've seen, it hasn't 
been unusual to see remarks about (previously) waiting for support in 
stable, and now about EAPI incompatibility, simply due to /parsing/ the 
ebuild.  This could offer a way around the problem, by separating initial 
parsing/dependency EAPI and actual build/merge EAPI.  The pre-source EAPI 
could state the EAPI support required to properly /source/parse/ the 
ebuild and generate the dependency tree, etc, while allowing the post-
source EAPI to be different then allows additional flexibility in actual 
build/merge required EAPI.

We'd then have two choices in terms of declaring pre-source support (as 
opposed to post-source, full merge support).

1) Simply that a compatible pre-source EAPI shouldn't blow up if sourced 
while calculating dependencies or the like -- the ebuild may be safely 
sourced and it shouldn't negatively affect the dependency tree for 
unrelated packages, but dependencies for that specific package may or may 
not be correct.

-OR-

2) That a compatible pre-source EAPI package, when sourced, should allow 
generation of a reasonably reliable dependency tree for the package in 
question, presumably including a PM upgrade as part of that dependency 
tree.

If we chose policy one, because unsupported pre-source EAPIs are 
explicitly NOT to be parsed, it would allow any arbitrary package format 
change as may eventually be found necessary, including breaking the bash-
parsable assumption, if at some point that is found convenient.  
Conversely, supported pre-source EAPIs could at least be depended upon 
not to break the PM or dependency resolution for other branches of the 
dependency tree.  As the ebuild was parsed, if a different post-source 
EAPI were found, a notice would be printed that said package couldn't be 
merged with the existing package manager, but the other branches of the 
update/merge would proceed, allowing the incompatibility for that package 
to be resolved later.

If we chose policy two and pre-source and post-source EAPIs differed, 
part of the dependency tree for that package should include a PM 
supporting the post-source EAPI, in which case the other (post-source 
EAPI compatible) branches could be merged, then the required post-EAPI PM 
(presumably an upgrade, remember, this would ONLY occur if the two EAPIs 
differed so it wouldn't happen in the general case) would be merged, that 
specific package dependency tree branch recalculated post PM upgrade, and 
then that package merged.

So the difference between policies for the user would be policy one would 
generally require a manual PM change intervention, while policy two could 
at least in theory (absent explicit blockers, etc) be handled entirely 
automatically.  Policy two has stricter requirements for developers, 
however, and would thus be easier to break.

OK, so it's off the wall, but tell me, is it useful and implementable, or 
just stupid?

-- 
Duncan - List replies preferred.  No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 3028 bytes --]

On Tue, 18 Dec 2007 09:53:50 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> Put directly, what is stopping us from actually allowing DIFFERENT
> pre- source and post-source EAPI values?

That's effectively what happens when a package manager sources a
current EAPI=1 in a variable ebuild.

> Here's the thinking.  In the various PM discussions I've seen, it
> hasn't been unusual to see remarks about (previously) waiting for
> support in stable, and now about EAPI incompatibility, simply due
> to /parsing/ the ebuild.  This could offer a way around the problem,
> by separating initial parsing/dependency EAPI and actual build/merge
> EAPI.  The pre-source EAPI could state the EAPI support required to
> properly /source/parse/ the ebuild and generate the dependency tree,
> etc, while allowing the post- source EAPI to be different then allows
> additional flexibility in actual build/merge required EAPI.
> 
> We'd then have two choices in terms of declaring pre-source support
> (as opposed to post-source, full merge support).

There's no advantage to doing so. If you don't support the EAPI, the
only thing you can do is say that you don't support the EAPI.

> 1) Simply that a compatible pre-source EAPI shouldn't blow up if
> sourced while calculating dependencies or the like -- the ebuild may
> be safely sourced and it shouldn't negatively affect the dependency
> tree for unrelated packages, but dependencies for that specific
> package may or may not be correct.

But all you get is the knowledge that the ebuild uses an unsupported
EAPI. Which you know already.

I should state this explicitly:

If an ebuild's EAPI isn't recognised by the package manager, the
package manager can't and mustn't "sort of" work with that ebuild;
there is no such thing as a "sort of supported" EAPI. The package
manager can either ignore the ebuild entirely or display it in some kind
of super fancy "masked due to EAPI" way -- and if it does the latter,
the *only* information the package manager has about the ebuild is that
its EAPI is unsupported. The package manager can't guess "ooh, well it
sets SLOT, so I can assume that SLOT means what I think it does" -- a
future EAPI might do something crazy like say that "if SLOT=dynamic, the
speshul pkg_slot function is used". The package manager can't even
assume that it knows what the unsupported EAPI's name really is or that
it knows what the unsupported package's version is.

> 2) That a compatible pre-source EAPI package, when sourced, should
> allow generation of a reasonably reliable dependency tree for the
> package in question, presumably including a PM upgrade as part of
> that dependency tree.

EAPIs aren't to specify the dependency tree.

There's the added problem that it breaks the concept of metadata cache.
That gets hairy.

> OK, so it's off the wall, but tell me, is it useful and
> implementable, or just stupid?

It's implementable. It would just be of no use.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Marius Mauch]

On Mon, 17 Dec 2007 23:20:01 +0100
Piotr Jaroszyński <peper@gentoo.org> wrote:

> Hello,
> 
> attaching the GLEP.
> 
> most current version:
> http://dev.gentoo.org/~peper/glep-0055.html
> http://dev.gentoo.org/~peper/glep-0055.txt

There is one significant problem not covered in the GLEP: If a package
contains an ebuild with a suffixed extension then all developers ever
working on that _package_ must use tools that can handle such ebuilds,
otherwise there will likely be problems regarding the Manifest handling
due to misclassifications of the file extension.

Marius
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

On Tue, 18 Dec 2007 16:45:01 +0100
Marius Mauch <genone@gentoo.org> wrote:
> There is one significant problem not covered in the GLEP: If a package
> contains an ebuild with a suffixed extension then all developers ever
> working on that _package_ must use tools that can handle such ebuilds,
> otherwise there will likely be problems regarding the Manifest
> handling due to misclassifications of the file extension.

This isn't a new requirement introduced by the GLEP. That's already the
case with EAPI things.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Marius Mauch]

On Wed, 19 Dec 2007 00:07:22 +0000
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Tue, 18 Dec 2007 16:45:01 +0100
> Marius Mauch <genone@gentoo.org> wrote:
> > There is one significant problem not covered in the GLEP: If a
> > package contains an ebuild with a suffixed extension then all
> > developers ever working on that _package_ must use tools that can
> > handle such ebuilds, otherwise there will likely be problems
> > regarding the Manifest handling due to misclassifications of the
> > file extension.
> 
> This isn't a new requirement introduced by the GLEP. That's already
> the case with EAPI things.

Partially correct. The difference is that the data that the compability
check is completely different, so while the requirement of using
compatible tools might already exist it's worth to spell out the new
meaning of compability. The potential impact is another change,
currently if tools couldn't handle specific ebuilds with specific EAPIs
they would not (silently) generate wrong data in the Manifest.

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Piotr Jaroszyński wrote:
> Hello,
> 
> attaching the GLEP.
> 
> most current version:
> http://dev.gentoo.org/~peper/glep-0055.html
> http://dev.gentoo.org/~peper/glep-0055.txt
> 
> 

How would it be different than having EAPI="string" put in a defined
position of the file?

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Piotr Jaroszyński]

On Wednesday 19 of December 2007 15:37:44 Luca Barbato wrote:
> How would it be different than having EAPI="string" put in a defined
> position of the file?

We wouldn't be able to take advantage of this GLEP for a year or so. But even 
putting that aside I still prefer the filename approach for its unambiguity.

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Piotr Jaroszyński wrote:
> On Wednesday 19 of December 2007 15:37:44 Luca Barbato wrote:
>> How would it be different than having EAPI="string" put in a defined
>> position of the file?
> 
> We wouldn't be able to take advantage of this GLEP for a year or so.

I don't see why, articulate.

> But even 
> putting that aside I still prefer the filename approach for its unambiguity.

Again you aren't telling which is the ambiguity.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Jim Ramsay]

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

Luca Barbato <lu_zero@gentoo.org> wrote:
> How would it be different than having EAPI="string" put in a defined
> position of the file?

It's not - It is just defining that position to be in the name of the
file instead of the contents :)

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Jim Ramsay wrote:
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> How would it be different than having EAPI="string" put in a defined
>> position of the file?
> 
> It's not - It is just defining that position to be in the name of the
> file instead of the contents :)

Exactly.
And this way is not elegant.
File name is used to uniquely identify a file in a system, not to decide how
the content of the file should be interpreted.
Never ever seen a file type extension with a version number.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 434 bytes --]

On Fri, 21 Dec 2007 02:52:16 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> Exactly.
> And this way is not elegant.
> File name is used to uniquely identify a file in a system, not to
> decide how the content of the file should be interpreted.
> Never ever seen a file type extension with a version number.

http://httpd.apache.org/docs/2.0/mod/mod_mime.html

You might find that interesting reading.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 02:52:16 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>> Exactly.
>> And this way is not elegant.
>> File name is used to uniquely identify a file in a system, not to
>> decide how the content of the file should be interpreted.
>> Never ever seen a file type extension with a version number.
> 
> http://httpd.apache.org/docs/2.0/mod/mod_mime.html
> 
> You might find that interesting reading.

Thanks. Actually coldwind also reminded me of mp3.
However, it is only 3 chars.
ebuild-1 is way too long, which is what I think not elegant.

And file extension like welcome.html.fr is quite self-explanatory.
But an total outsider has no chance to deduce what the 1 in ebuild-1 means on
his own.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

On Fri, 21 Dec 2007 10:59:14 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> However, it is only 3 chars.
> ebuild-1 is way too long, which is what I think not elegant.

Why? This is Unix, not dos.

> And file extension like welcome.html.fr is quite self-explanatory.
> But an total outsider has no chance to deduce what the 1 in ebuild-1
> means on his own.

A total outsider doesn't need to know. The only people who will be
dealing with .ebuild-* files are developers and power users.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Thomas Pani]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 10:59:14 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>> And file extension like welcome.html.fr is quite self-explanatory.
>> But an total outsider has no chance to deduce what the 1 in ebuild-1
>> means on his own.
> 
> A total outsider doesn't need to know. The only people who will be
> dealing with .ebuild-* files are developers and power users.
> 
And you are trying to set an even higher barrier for people to reach
that level. How many power users or devs do actually care/know what
EAPI=1 means?

Regards,
thomas
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

On Fri, 21 Dec 2007 10:58:15 +0100
Thomas Pani <thomas.pani@gmail.com> wrote:
> Ciaran McCreesh wrote:
> > On Fri, 21 Dec 2007 10:59:14 +0800
> > Zhang Le <r0bertz@gentoo.org> wrote:
> >> And file extension like welcome.html.fr is quite self-explanatory.
> >> But an total outsider has no chance to deduce what the 1 in
> >> ebuild-1 means on his own.
> > 
> > A total outsider doesn't need to know. The only people who will be
> > dealing with .ebuild-* files are developers and power users.
> > 
> And you are trying to set an even higher barrier for people to reach
> that level. How many power users or devs do actually care/know what
> EAPI=1 means?

Developers have to know about EAPIs. It's part of knowing how to write
ebuilds. There's no way around that -- if you're writing ebuilds, you
have to know what you are and aren't allowed to do in those ebuilds.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Rémi Cardona]

Ciaran McCreesh a écrit :
> Developers have to know about EAPIs. It's part of knowing how to write
> ebuilds. There's no way around that -- if you're writing ebuilds, you
> have to know what you are and aren't allowed to do in those ebuilds.

Then please try to keep things simple :)

The majority of devs don't want to know how portage or paludis work
internally, that's not what interests most of us.

On a somewhat related note : I noticed that among the massive thread,
you have brought up several times the issue of cache generation, saying
that it was a complicated process.

Maybe this process needs to be reworked before the whole EAPI issue can
be resolved?

Cheers,

Rémi
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]

On Fri, 21 Dec 2007 14:29:25 +0100
Rémi Cardona <remi@gentoo.org> wrote:
> Ciaran McCreesh a écrit :
> > Developers have to know about EAPIs. It's part of knowing how to
> > write ebuilds. There's no way around that -- if you're writing
> > ebuilds, you have to know what you are and aren't allowed to do in
> > those ebuilds.
> 
> Then please try to keep things simple :)

*Using* EAPIs is simple. *Designing* them, not so much.

> The majority of devs don't want to know how portage or paludis work
> internally, that's not what interests most of us.

Which is fine. But then, the majority of devs shouldn't expect to be
able to provide opinions when it comes to the more technical aspects.

> On a somewhat related note : I noticed that among the massive thread,
> you have brought up several times the issue of cache generation,
> saying that it was a complicated process.
> 
> Maybe this process needs to be reworked before the whole EAPI issue
> can be resolved?

That's partly what the GLEP is doing. Making it any simpler,
unfortunately, would involve either a huuuuuuge performance hit (we're
talking two orders of magnitude here) or removing metadata from the
ebuilds entirely -- neither of which are viable solutions.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Steve Long]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 14:29:25 +0100
>> The majority of devs don't want to know how portage or paludis work
>> internally, that's not what interests most of us.
> 
> Which is fine. But then, the majority of devs shouldn't expect to be
> able to provide opinions when it comes to the more technical aspects.
>
Yes, but they can smell a nasty hack when they see one; starting with the
fact that the API is no longer as clean.

>> On a somewhat related note : I noticed that among the massive thread,
>> you have brought up several times the issue of cache generation,
>> saying that it was a complicated process.
>> 
>> Maybe this process needs to be reworked before the whole EAPI issue
>> can be resolved?
> 
> That's partly what the GLEP is doing. Making it any simpler,
> unfortunately, would involve either a huuuuuuge performance hit (we're
> talking two orders of magnitude here) or removing metadata from the
> ebuilds entirely -- neither of which are viable solutions.
> 
Oh, I thought this wasn't about performance? Nor indeed about cache
generation.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

On Mon, 24 Dec 2007 11:19:18 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > Which is fine. But then, the majority of devs shouldn't expect to be
> > able to provide opinions when it comes to the more technical
> > aspects.
> >
> Yes, but they can smell a nasty hack when they see one; starting with
> the fact that the API is no longer as clean.

Clearly not...

> >> On a somewhat related note : I noticed that among the massive
> >> thread, you have brought up several times the issue of cache
> >> generation, saying that it was a complicated process.
> >> 
> >> Maybe this process needs to be reworked before the whole EAPI issue
> >> can be resolved?
> > 
> > That's partly what the GLEP is doing. Making it any simpler,
> > unfortunately, would involve either a huuuuuuge performance hit
> > (we're talking two orders of magnitude here) or removing metadata
> > from the ebuilds entirely -- neither of which are viable solutions.
> > 
> Oh, I thought this wasn't about performance? Nor indeed about cache
> generation.

The GLEP is not about performance, but any solution that forces the
introduction of a slowdown of more than, say, 20%, isn't viable. In
particular, making a typical emerge -pv world take of the order of 0.1s
per c/p-v's metadata that's needed (as a very rough idea, we're talking
a thousand upwards of these on a typical system) isn't even remotely
feasible.

And no, the GLEP doesn't directly address cache generation. But
equally, it can't ignore it simply because without some form of
static metadata cache package managers can't be implemented in a way
acceptable to end users.

You see, there's this thing called the "big picture"...

-- 
Ciaran McCreesh
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Thomas Pani wrote:
> Ciaran McCreesh wrote:
>> On Fri, 21 Dec 2007 10:59:14 +0800
>> Zhang Le <r0bertz@gentoo.org> wrote:
>>> And file extension like welcome.html.fr is quite self-explanatory.
>>> But an total outsider has no chance to deduce what the 1 in ebuild-1
>>> means on his own.
>> A total outsider doesn't need to know. The only people who will be
>> dealing with .ebuild-* files are developers and power users.
>>
> And you are trying to set an even higher barrier for people to reach
> that level. How many power users or devs do actually care/know what
> EAPI=1 means?

http://www.gentoo.org/proj/en/council/meeting-logs/20071108-summary.txt

We should've made it appear in our front page or GWN.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Donnie Berkholz]

On 23:20 Mon 17 Dec     , Piotr Jaroszyński wrote:
> Abstract
> ========
> 
> This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for
> example, foo-1.2.3.ebuild-1).
> 
> Motivation
> ==========
> 
> Including EAPI in the ebuild file extension has the following advantages:
> 
>   *  Possibility to extend the versioning rules in an EAPI, and to use them
>      immediately in the Gentoo tree. For example, addition of the scm suffix -
>      GLEP54 [#GLEP54]_.
> 
>   *  Possibility to extend the behaviour of inherit and add new global scope
>      functions (as a result of not sourcing ebuilds with unsupported EAPI).

Here's some other ideas for how to express EAPI. What if we:

Used EAPI-named subdirectories instead of tagging it into the filename?

Used (and required) filesystem extended attributes?

Stuck ranges into metadata.xml for which EAPIs applied?

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Donnie Berkholz wrote:
> On 23:20 Mon 17 Dec     , Piotr Jaroszyński wrote:
>> Abstract
>> ========
>>
>> This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for
>> example, foo-1.2.3.ebuild-1).
>>
>> Motivation
>> ==========
>>
>> Including EAPI in the ebuild file extension has the following advantages:
>>
>>   *  Possibility to extend the versioning rules in an EAPI, and to use them
>>      immediately in the Gentoo tree. For example, addition of the scm suffix -
>>      GLEP54 [#GLEP54]_.
>>
>>   *  Possibility to extend the behaviour of inherit and add new global scope
>>      functions (as a result of not sourcing ebuilds with unsupported EAPI).
> 
> Here's some other ideas for how to express EAPI. What if we:
> 
> Used EAPI-named subdirectories instead of tagging it into the filename?
> 
> Used (and required) filesystem extended attributes?
> 
> Stuck ranges into metadata.xml for which EAPIs applied?

Before spending even more time on it, could we try to come up with a
definition of what eapi is, which problem is trying to solve and put
that somewhere that isn't a long thread or an handful of threads
scattered across mailing lists.

Then we could think about this implementation detail if the best
implementation for it is really sticking tags somewhere in the ebuild.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Donnie Berkholz]

On 03:31 Thu 20 Dec     , Luca Barbato wrote:
> Before spending even more time on it, could we try to come up with a
> definition of what eapi is, which problem is trying to solve and put
> that somewhere that isn't a long thread or an handful of threads
> scattered across mailing lists.
> 
> Then we could think about this implementation detail if the best
> implementation for it is really sticking tags somewhere in the ebuild.

I dug through some old mailing-list archives and found some threads from 
gentoo-dev in July-August 2005 about EBUILD_FORMAT:

http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg02668.html

And here's the post where vapier coined the term EAPI:

http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg02692.html

It moved over to gentoo-portage-dev later on:

http://www.mail-archive.com/gentoo-portage-dev@lists.gentoo.org/msg00203.html
http://www.mail-archive.com/gentoo-portage-dev@lists.gentoo.org/msg00207.html

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Donnie Berkholz wrote:
> On 03:31 Thu 20 Dec     , Luca Barbato wrote:
>> Before spending even more time on it, could we try to come up with a
>> definition of what eapi is, which problem is trying to solve and put
>> that somewhere that isn't a long thread or an handful of threads
>> scattered across mailing lists.
>>
>> Then we could think about this implementation detail if the best
>> implementation for it is really sticking tags somewhere in the ebuild.
> 
> I dug through some old mailing-list archives and found some threads from 
> gentoo-dev in July-August 2005 about EBUILD_FORMAT:
> 
> http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg02668.html
> 
> And here's the post where vapier coined the term EAPI:
> 
> http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg02692.html
> 
> It moved over to gentoo-portage-dev later on:
> 
> http://www.mail-archive.com/gentoo-portage-dev@lists.gentoo.org/msg00203.html
> http://www.mail-archive.com/gentoo-portage-dev@lists.gentoo.org/msg00207.html
> 

Sigh, ok, but

> that isn't a long thread or an handful of threads
> scattered across mailing lists.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]

On Thu, 20 Dec 2007 03:31:14 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Before spending even more time on it, could we try to come up with a
> definition of what eapi is, which problem is trying to solve and put
> that somewhere that isn't a long thread or an handful of threads
> scattered across mailing lists.

An EAPI is a named set of rules telling a package manager how to deal
with a particular ebuild and related files, and telling ebuilds upon
what they may or may not rely from the package manager. It defines
aspects of package manager / ebuild relation including metadata,
environment and additional behavioural restrictions.

EAPI names are not orderable and have no meaning to the package manager
other than their literal value.

EAPIs may be entirely incompatible with each other, or they may be mere
extensions of a different EAPI, or they may be a subset of a different
EAPI, or any combination thereof.

A cat/pkg-ver has exactly one EAPI. That EAPI belongs to the
cat/pkg-ver as a whole, and is static across that cat/pkg-ver.

EAPI is part of a cat/pkg-ver's metadata. All existing EAPIs require
that EAPI follows the environment invariancy rules.

If a package manager does not support a particular EAPI, the
*only* thing it may assume is that it does not support that particular
EAPI. It may not assume that it knows what any aspect of that
cat/pkg-ver's metadata is, nor may it assume that it knows what cat,
pkg or ver are.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Ciaran McCreesh wrote:
> On Thu, 20 Dec 2007 03:31:14 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Before spending even more time on it, could we try to come up with a
>> definition of what eapi is, which problem is trying to solve and put
>> that somewhere that isn't a long thread or an handful of threads
>> scattered across mailing lists.
> 
> An EAPI is a named set of rules telling a package manager how to deal
> with a particular ebuild and related files, and telling ebuilds upon
> what they may or may not rely from the package manager. It defines
> aspects of package manager / ebuild relation including metadata,
> environment and additional behavioural restrictions.
> 
> EAPI names are not orderable and have no meaning to the package manager
> other than their literal value.
> 
> EAPIs may be entirely incompatible with each other, or they may be mere
> extensions of a different EAPI, or they may be a subset of a different
> EAPI, or any combination thereof.
> 
> A cat/pkg-ver has exactly one EAPI. That EAPI belongs to the
> cat/pkg-ver as a whole, and is static across that cat/pkg-ver.
> 
> EAPI is part of a cat/pkg-ver's metadata. All existing EAPIs require
> that EAPI follows the environment invariancy rules.
> 
> If a package manager does not support a particular EAPI, the
> *only* thing it may assume is that it does not support that particular
> EAPI. It may not assume that it knows what any aspect of that
> cat/pkg-ver's metadata is, nor may it assume that it knows what cat,
> pkg or ver are.

Ok, that seems a fine definition of what an eapi is. Everybody agrees on it?

About the problem it is trying to solve, I think it basically boils down
to make sure the package manager:

- ignores ebuilds with syntax different from the one it can handle
- can be safely updated even in the situation the tree has ebuilds it
cannot parse.

eapi, as defined above, does address those point in the best way?
those point are what we are trying to address with eapi?


-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Marius Mauch]

On Thu, 20 Dec 2007 08:10:13 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:

> Ok, that seems a fine definition of what an eapi is. Everybody agrees on it?

Nope. EAPI (from my POV) defines the API that a package manager has to export to an ebuild/eclass. That includes syntax and semantics of exported and expected functions and variables (IOW the content of ebuilds/eclasses), but does not contain naming and versioning rules (as those impact cross-package relationships).

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Marius Mauch wrote:
> On Thu, 20 Dec 2007 08:10:13 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
> 
>> Ok, that seems a fine definition of what an eapi is. Everybody agrees on it?
> 
> Nope. EAPI (from my POV) defines the API that a package manager has to export
> to an ebuild/eclass. That includes syntax and semantics of exported and expected
> functions and variables (IOW the content of ebuilds/eclasses), but does not
> contain naming and versioning rules (as those impact cross-package relationships).

This restricted definition is ok for everybody?

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Doug Klima]

Luca Barbato wrote:
> Marius Mauch wrote:
>   
>> On Thu, 20 Dec 2007 08:10:13 +0100
>> Luca Barbato <lu_zero@gentoo.org> wrote:
>>
>>     
>>> Ok, that seems a fine definition of what an eapi is. Everybody agrees on it?
>>>       
>> Nope. EAPI (from my POV) defines the API that a package manager has to export
>> to an ebuild/eclass. That includes syntax and semantics of exported and expected
>> functions and variables (IOW the content of ebuilds/eclasses), but does not
>> contain naming and versioning rules (as those impact cross-package relationships).
>>     
>
> This restricted definition is ok for everybody?
>
> lu
>
>   
Logical and proper to me.
-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Sven Vermeulen]

On Dec 27, 2007 11:40 PM, Doug Klima <cardoe@gentoo.org> wrote:
[... EAPI is stuff PM supports/exports to the ebuild ...]
> Logical and proper to me.

Actually, when I'm asked what EAPI is, I just say "EAPI is a standard
definition for the ebuild structure, implying supporting features from
the package manager."

Most of the time, the user is happy with the answer ;-)

Wkr,
  Sven Vermeulen
-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

On Thu, 27 Dec 2007 23:26:27 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Marius Mauch wrote:
> > Nope. EAPI (from my POV) defines the API that a package manager has
> > to export to an ebuild/eclass. That includes syntax and semantics
> > of exported and expected functions and variables (IOW the content
> > of ebuilds/eclasses), but does not contain naming and versioning
> > rules (as those impact cross-package relationships).
> 
> This restricted definition is ok for everybody?

The restricted definition is certainly OK, but I'm not convinced that
the restriction is necessary. There's no particular reason that new
version formats can't be introduced in a new EAPI so long as the
version strings don't appear in ebuilds using older EAPIs or in
profiles. Ditto for naming rules.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Santiago M. Mola]

On Dec 28, 2007 1:03 PM, Ciaran McCreesh
<ciaran.mccreesh@blueyonder.co.uk> wrote:
>
> There's no particular reason that new
> version formats can't be introduced in a new EAPI so long as the
> version strings don't appear in ebuilds using older EAPIs or in
> profiles. Ditto for naming rules.
>

Errr... so should we use new files in profiles for such new formats?
(for example, p.masking an ebuild with a new version format).

-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

On Fri, 28 Dec 2007 13:25:13 +0100
"Santiago M. Mola" <coldwind@gentoo.org> wrote:
> On Dec 28, 2007 1:03 PM, Ciaran McCreesh
> <ciaran.mccreesh@blueyonder.co.uk> wrote:
> > There's no particular reason that new
> > version formats can't be introduced in a new EAPI so long as the
> > version strings don't appear in ebuilds using older EAPIs or in
> > profiles. Ditto for naming rules.
> 
> Errr... so should we use new files in profiles for such new formats?
> (for example, p.masking an ebuild with a new version format).

Possibly. Currently there's simply no way of doing it, nor of using
non-EAPI-0 features anywhere in profiles (you can't, for example, use
slot deps in package.mask).

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Santiago M. Mola]

On Dec 28, 2007 1:28 PM, Ciaran McCreesh
<ciaran.mccreesh@blueyonder.co.uk> wrote:
> On Fri, 28 Dec 2007 13:25:13 +0100
> "Santiago M. Mola" <coldwind@gentoo.org> wrote:
> > On Dec 28, 2007 1:03 PM, Ciaran McCreesh
> > <ciaran.mccreesh@blueyonder.co.uk> wrote:
> > > There's no particular reason that new
> > > version formats can't be introduced in a new EAPI so long as the
> > > version strings don't appear in ebuilds using older EAPIs or in
> > > profiles. Ditto for naming rules.
> >
> > Errr... so should we use new files in profiles for such new formats?
> > (for example, p.masking an ebuild with a new version format).
>
> Possibly. Currently there's simply no way of doing it, nor of using
> non-EAPI-0 features anywhere in profiles (you can't, for example, use
> slot deps in package.mask).
>

It'd be nice to agree a new profile format before accepting version
format changes.

In the case of slot deps, it'd be desirable to use them in
package.mask, just desirable. But with version format changes we're
introducing ebuilds which can't be handled in package.mask, that's a
great loss of functionality.

GLEPs 54 and 55 could wait until we have figured out how to apply them
properly and without loss of current functionality.

--
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: EAPI definition Was: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> posted
20071228122810.1bbe2637@blueyonder.co.uk, excerpted below, on  Fri, 28 Dec
2007 12:28:10 +0000:

> On Fri, 28 Dec 2007 13:25:13 +0100
> "Santiago M. Mola" <coldwind@gentoo.org> wrote:
>> On Dec 28, 2007 1:03 PM, Ciaran McCreesh
>> <ciaran.mccreesh@blueyonder.co.uk> wrote:
>> > There's no particular reason that new version formats can't be
>> > introduced in a new EAPI so long as the version strings don't appear
>> > in ebuilds using older EAPIs or in profiles. Ditto for naming rules.
>> 
>> Errr... so should we use new files in profiles for such new formats?
>> (for example, p.masking an ebuild with a new version format).
> 
> Possibly. Currently there's simply no way of doing it, nor of using
> non-EAPI-0 features anywhere in profiles (you can't, for example, use
> slot deps in package.mask).

Requesting clarification of a point, here:

I understand the ban on non-EAPI-0 features in in-tree profiles, since 
users could be using old PMs, but it's fine using them in /etc/portage/*, 
provided one has upgraded to an appropriately compatible PM, correct?

I ask because based on the kde overlay documentation, I have a lot of 
entries like this in /etc/portage/package.keywords:

# kde4 overlay kde-base
kde-base/kdelibs:kde-svn                **

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: EAPI definition Was: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Marius Mauch]

On Fri, 28 Dec 2007 23:34:44 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> I understand the ban on non-EAPI-0 features in in-tree profiles, since 
> users could be using old PMs, but it's fine using them in /etc/portage/*, 
> provided one has upgraded to an appropriately compatible PM, correct?

Yes (in case of portage).

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Marius Mauch]

On Fri, 28 Dec 2007 12:03:12 +0000
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Thu, 27 Dec 2007 23:26:27 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
> > Marius Mauch wrote:
> > > Nope. EAPI (from my POV) defines the API that a package manager has
> > > to export to an ebuild/eclass. That includes syntax and semantics
> > > of exported and expected functions and variables (IOW the content
> > > of ebuilds/eclasses), but does not contain naming and versioning
> > > rules (as those impact cross-package relationships).
> > 
> > This restricted definition is ok for everybody?
> 
> The restricted definition is certainly OK, but I'm not convinced that
> the restriction is necessary. There's no particular reason that new
> version formats can't be introduced in a new EAPI so long as the
> version strings don't appear in ebuilds using older EAPIs or in
> profiles.

The issue is with comparison rules. For the current use case that's not
an issue as it's simply a superset, so we could just use the new rules
for everything. But if the rules are changed in an incompatible way,
which rules would be used to compare version(EAPI_X) with version(EAPI_Y)?

> Ditto for naming rules.

Those are even more of an issue, as they apply before we know the
eventual EAPI (need to access the category/package directory before you
can parse the ebuild filename)

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

On Mon, 31 Dec 2007 15:46:06 +0100
Marius Mauch <genone@gentoo.org> wrote:
> The issue is with comparison rules. For the current use case that's
> not an issue as it's simply a superset, so we could just use the new
> rules for everything. But if the rules are changed in an incompatible
> way, which rules would be used to compare version(EAPI_X) with
> version(EAPI_Y)?

You pretty much have to have a way of mapping an EAPI version onto an
absolute version if you want to handle it sanely.

> > Ditto for naming rules.
> 
> Those are even more of an issue, as they apply before we know the
> eventual EAPI (need to access the category/package directory before
> you can parse the ebuild filename)

Mmm, no. You have some concept of a superset of all supported naming
rules, then refine once you've extracted the EAPI.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Marius Mauch]

On Mon, 31 Dec 2007 15:09:33 +0000
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Mon, 31 Dec 2007 15:46:06 +0100
> Marius Mauch <genone@gentoo.org> wrote:
> > The issue is with comparison rules. For the current use case that's
> > not an issue as it's simply a superset, so we could just use the new
> > rules for everything. But if the rules are changed in an incompatible
> > way, which rules would be used to compare version(EAPI_X) with
> > version(EAPI_Y)?
> 
> You pretty much have to have a way of mapping an EAPI version onto an
> absolute version if you want to handle it sanely.

Right, and that's likely to cause a mess in the long run IMO.

> > > Ditto for naming rules.
> > 
> > Those are even more of an issue, as they apply before we know the
> > eventual EAPI (need to access the category/package directory before
> > you can parse the ebuild filename)
> 
> Mmm, no. You have some concept of a superset of all supported naming
> rules, then refine once you've extracted the EAPI.

Assuming the current package manager supports all used EAPIs, otherwise
a formerly invalid name could still break it.

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

On Tue, 1 Jan 2008 05:50:11 +0100
Marius Mauch <genone@gentoo.org> wrote:
> > You pretty much have to have a way of mapping an EAPI version onto
> > an absolute version if you want to handle it sanely.
> 
> Right, and that's likely to cause a mess in the long run IMO.

Eh, it's already necessary if package managers want to support things
like CPAN natively. It's not too big a deal.

> > Mmm, no. You have some concept of a superset of all supported naming
> > rules, then refine once you've extracted the EAPI.
> 
> Assuming the current package manager supports all used EAPIs,
> otherwise a formerly invalid name could still break it.

'Twould just have to ignore them.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Thomas Pani]

Here's why I think you can't -- or at least shouldn't -- put EAPI into
the filename.

>From your EAPI definition:
> A cat/pkg-ver has exactly one EAPI. That EAPI belongs to the
> cat/pkg-ver as a whole, and is static across that cat/pkg-ver.

It's clearly NOT the purpose of a filename to describe how the contents
of a file are structured/formatted/encoded/etc. It's sole purpose is to
uniquely identify a file.
Example: I use .txt to identify my text documents. However, I don't use
.txt-utf-8, .txt-latin-1, .txt-iso-8859-15 just because their encoding
differs.

As cat/pkg-ver ultimately is ONE file in the filesystem, there's no
reason to put any information about the EAPI in the filename.

I still don't get why EAPI=xxx is soooo bad. Obviously the GLEP (and the
last 500 comments lack to explain that. Ebuilds are bash. EAPI=xxx is
bash syntax.

If you just don't like EAPI being defined as variable (because future
EAPIs could define that EAPI is assigned via a function), there are
other ways to put this into the ebuild. Eg. Python PEP 0263 ([1])
proposes a way to declare the encoding inside of the source file. Same
could be done for the EAPI.
Or just write a GLEP that states EAPI has to be assigned via the EAPI
variable. You're trying to *set* a standard here, so act accordingly.

thomas

[1] http://www.python.org/dev/peps/pep-0263/
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

On Thu, 20 Dec 2007 11:37:01 +0100
Thomas Pani <thomas.pani@gmail.com> wrote:
> As cat/pkg-ver ultimately is ONE file in the filesystem, there's no
> reason to put any information about the EAPI in the filename.

Sure there is. It's the sanest place to put it such that it's available
when it's needed -- that is, before the ebuild is sourced.

> I still don't get why EAPI=xxx is soooo bad. Obviously the GLEP (and
> the last 500 comments lack to explain that. Ebuilds are bash.
> EAPI=xxx is bash syntax.

Uh, I've explained it far too many times in this thread already. Go
back and read. Don't post again until you understand it.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Thomas Pani]

Ciaran McCreesh wrote:
> On Thu, 20 Dec 2007 11:37:01 +0100
> Thomas Pani <thomas.pani@gmail.com> wrote:
>> As cat/pkg-ver ultimately is ONE file in the filesystem, there's no
>> reason to put any information about the EAPI in the filename.
> 
> Sure there is. It's the sanest place to put it such that it's available
> when it's needed -- that is, before the ebuild is sourced.
> 
>> I still don't get why EAPI=xxx is soooo bad. Obviously the GLEP (and
>> the last 500 comments lack to explain that. Ebuilds are bash.
>> EAPI=xxx is bash syntax.
> 
> Uh, I've explained it far too many times in this thread already. Go
> back and read. Don't post again until you understand it.
> 
I DO understand. You say that explicitly having EAPI=xxx in the first
non-comment line / in the ebuild header / whereever imposes restrictions
on the ebuild format itself that go beyond "it has to be bash". That's
right.

But you're totally ignoring my point. So once again: You're trying to
*SET* a standard here. There are lots of people telling you that they're
not happy with the proposal to change the ebuild filename suffix. There
seem to be less people opposed to having that ebuild format restriction.
So either choose the one that's accepted by the majority (and I'm not
saying that EAPI=xxx is the one; I'm saying that we'll have to figure
that out), or think of something completely new.

Thomas Pani
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

On Thu, 20 Dec 2007 12:06:59 +0100
Thomas Pani <thomas.pani@gmail.com> wrote:
> But you're totally ignoring my point. So once again: You're trying to
> *SET* a standard here. There are lots of people telling you that
> they're not happy with the proposal to change the ebuild filename
> suffix. There seem to be less people opposed to having that ebuild
> format restriction. So either choose the one that's accepted by the
> majority (and I'm not saying that EAPI=xxx is the one; I'm saying
> that we'll have to figure that out), or think of something completely
> new.

The ebuild format restriction does not solve the problem at hand.

I'm guessing there're lots of people moaning because they think they
understand filenames and can therefore comment. Unfortunately, most of
those people don't understand the metadata generation process, and
therefore can't comment usefully...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Denis Dupeyron]

On Dec 20, 2007 12:12 PM, Ciaran McCreesh
<ciaran.mccreesh@blueyonder.co.uk> wrote:
> I'm guessing there're lots of people moaning because they think they
> understand filenames and can therefore comment. Unfortunately, most of
> those people don't understand the metadata generation process, and
> therefore can't comment usefully...

Stop guessing, then. You're way off. You apparently do not understand
that an assertion without justification has no value in a serious
discussion. Even it that has already been explained somewhere else, it
may have been interpreted differently by different people (assuming
they can find it). And sorry to disappoint you but you're not alway
right. You have to give people a chance to contradict you, for your
own good. Also, please stop thinking people have the exact same thing
in mind as you because that leads to misunderstandings. All of us
being different and thinking differently is why we are this good.

There's nothing you can do about this, it's human nature. The day
you'll understand all of this you'll be a much better dev and human
being in general. And this day, working with you will be lots of fun.
Too bad you were late when the specification for Man was written,
because it seems we would have been much better than we are, and it
would have been easier for you now.

Denis.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

On Thu, 20 Dec 2007 14:54:10 +0100
"Denis Dupeyron" <calchan@gentoo.org> wrote:
> On Dec 20, 2007 12:12 PM, Ciaran McCreesh
> <ciaran.mccreesh@blueyonder.co.uk> wrote:
> > I'm guessing there're lots of people moaning because they think they
> > understand filenames and can therefore comment. Unfortunately, most
> > of those people don't understand the metadata generation process,
> > and therefore can't comment usefully...
> 
> Stop guessing, then. You're way off. You apparently do not understand
> that an assertion without justification has no value in a serious
> discussion.

I was being nice. Next time I'll post a list of names of people who
don't understand the metadata generation process and who therefore
can't comment usefully...

> Even it that has already been explained somewhere else, it
> may have been interpreted differently by different people (assuming
> they can find it).

How they interpret is different from the objective fact of what the
process is.

> And sorry to disappoint you but you're not alway
> right. You have to give people a chance to contradict you, for your
> own good.

People who know what they're talking about are more than welcome to
contradict me. People who don't understand what's being discussed
(which is most people in this thread) need to learn to stop wasting
people's time.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Ciaran McCreesh wrote:
> People who know what they're talking about are more than welcome to
> contradict me. People who don't understand what's being discussed
> (which is most people in this thread) need to learn to stop wasting
> people's time.

Point the documents that could help people getting an informed opinion,
they would have to be referenced in the GLEP anyway.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 781 bytes --]

On Fri, 21 Dec 2007 03:46:00 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > People who know what they're talking about are more than welcome to
> > contradict me. People who don't understand what's being discussed
> > (which is most people in this thread) need to learn to stop wasting
> > people's time.
> 
> Point the documents that could help people getting an informed
> opinion, they would have to be referenced in the GLEP anyway.

There are none. If anyone really wants to know, they can read the code
for their package manager of choice (or better, all of them).

And no, it's not worth writing them. If people have time to spend
documenting ebuildy things, there are a lot more useful places to
start.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 03:46:00 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Ciaran McCreesh wrote:
>>> People who know what they're talking about are more than welcome to
>>> contradict me. People who don't understand what's being discussed
>>> (which is most people in this thread) need to learn to stop wasting
>>> people's time.
>> Point the documents that could help people getting an informed
>> opinion, they would have to be referenced in the GLEP anyway.
> 
> There are none. If anyone really wants to know, they can read the code
> for their package manager of choice (or better, all of them).

Then I suggest stop this discussion and make a documentation first.
Seriously.

> And no, it's not worth writing them. If people have time to spend
> documenting ebuildy things, there are a lot more useful places to
> start.

It worths. It will influence our future.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

On Fri, 21 Dec 2007 11:26:06 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> > There are none. If anyone really wants to know, they can read the
> > code for their package manager of choice (or better, all of them).
> 
> Then I suggest stop this discussion and make a documentation first.
> Seriously.

The GLEP doesn't require that everyone understand it in order to
progress. All it requires is that the package manager people agree that
it's the best way forward and that developers can follow the rules it
adds.

> > And no, it's not worth writing them. If people have time to spend
> > documenting ebuildy things, there are a lot more useful places to
> > start.
> 
> It worths. It will influence our future.

And bringing devmanual up to date will influence it a lot more.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 11:26:06 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>>> And no, it's not worth writing them. If people have time to spend
>>> documenting ebuildy things, there are a lot more useful places to
>>> start.
>> It worths. It will influence our future.
> 
> And bringing devmanual up to date will influence it a lot more.

That's a different question. Please keep on topic.
For this glep to pass, we don't need devmanual to be up-to-date.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Thu, 20 Dec 2007 14:54:10 +0100
> "Denis Dupeyron" <calchan@gentoo.org> wrote:
>> On Dec 20, 2007 12:12 PM, Ciaran McCreesh
>> <ciaran.mccreesh@blueyonder.co.uk> wrote:
>>> I'm guessing there're lots of people moaning because they think they
>>> understand filenames and can therefore comment. Unfortunately, most
>>> of those people don't understand the metadata generation process,
>>> and therefore can't comment usefully...
>> Stop guessing, then. You're way off. You apparently do not understand
>> that an assertion without justification has no value in a serious
>> discussion.
> 
> I was being nice. Next time I'll post a list of names of people who
> don't understand the metadata generation process and who therefore
> can't comment usefully...

no slang in one's words is just a minimum requirement of communication.

> 
>> And sorry to disappoint you but you're not alway
>> right. You have to give people a chance to contradict you, for your
>> own good.
> 
> People who know what they're talking about are more than welcome to
> contradict me. People who don't understand what's being discussed
> (which is most people in this thread) need to learn to stop wasting
> people's time.

I see it differently.
Everyone participated in this discussion has shown their concerns about their
distro.
If someone don't understand, we should help them to understand, not just
exclude them from this discussion.
They should learn, however we should at least give them directions.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

On Fri, 21 Dec 2007 11:09:44 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> no slang in one's words is just a minimum requirement of
> communication.

There was no slang. That was plain English.

> I see it differently.
> Everyone participated in this discussion has shown their concerns
> about their distro.
> If someone don't understand, we should help them to understand, not
> just exclude them from this discussion.
> They should learn, however we should at least give them directions.

Which is all very well, but highly impractical. If someone wants to
write up a document explaining the metadata process then they're more
than welcome to -- but there are much more useful things that could be
documented if people had time...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 11:09:44 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>> I see it differently.
>> Everyone participated in this discussion has shown their concerns
>> about their distro.
>> If someone don't understand, we should help them to understand, not
>> just exclude them from this discussion.
>> They should learn, however we should at least give them directions.
> 
> Which is all very well, but highly impractical. If someone wants to
> write up a document explaining the metadata process then they're more
> than welcome to -- but there are much more useful things that could be
> documented if people had time...

I am afraid if we want all people accept this GLEP wholeheartedly, someone
ought to be stand out and take this responsibility.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

On Fri, 21 Dec 2007 11:38:43 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> I am afraid if we want all people accept this GLEP wholeheartedly,
> someone ought to be stand out and take this responsibility.

No no, we want all the people who are qualified to discuss it to accept
it, and the rest to accept that those people know what they're doing.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 11:38:43 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>> I am afraid if we want all people accept this GLEP wholeheartedly,
>> someone ought to be stand out and take this responsibility.
> 
> No no, we want all the people who are qualified to discuss it to accept
> it, and the rest to accept that those people know what they're doing.

By "all people", I mean all those who have participated in this discussion.
They shown their concern.
We should listen to what they said.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

On Fri, 21 Dec 2007 11:56:35 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> By "all people", I mean all those who have participated in this
> discussion. They shown their concern.
> We should listen to what they said.

Even when what they said was nonsense and the equivalent of running
around saying that aliens are mind controlling the government and that
we should make all developers wear tinfoil hats to prevent it? Because
that's the level of contribution we're getting from some of the
participants in this thread...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 11:56:35 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>> By "all people", I mean all those who have participated in this
>> discussion. They shown their concern.
>> We should listen to what they said.
> 
> Even when what they said was nonsense 

No nonsense, so far, IMO.

The question is really simple.
Whether we should have two different place to define EAPI?
Proponents are trying to prove that we should at least need it be in file name.
However so far they are not successful in proving that.
They just said you don't understand and you don't need to be able to influence
 on this decision.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]

On Friday 21 December 2007 05:25:00 Zhang Le wrote:
> The question is really simple.
> Whether we should have two different place to define EAPI?

We need two places because it wasn't implemented properly in the first place 
and we want to retain backwards compatibility for people who use old versions 
of portage. The whole point is to keep a sane upgrade path available 
indefinitely for people with old versions of portage.

> Proponents are trying to prove that we should at least need it be in file
> name.

We need the file name to change because otherwise old versions of portage will 
try to source the ebuild when the EAPI is unknown. This either blocks new 
useful features that will make old versions of portage fail to source them or 
results in more bug reports with zillions of dupes (like the bugs in [1]) 
because people with ancient versions of portage feel the need to report bug 
reports when portage fails after a sync.

At the very least it means waiting for a year between a release with a version 
of portage that supports this and an EAPI that takes advantage of it. So now 
that leaves the question whether we want to change the file name once and 
hope that we won't need to do it again or whether we want to use the 
technically more flexible way where the file name changes whenever a new EAPI 
gets agreed upon.

Or alternatively whether we want to limit ourselves by using an inferior 
solution that limits or delays progress considerably and results in more bug 
reports with zillions of dupes...

[1] http://www.gentoo.org/proj/en/portage/doc/common-problems.xml

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Bo Ørsted Andresen wrote:
> On Friday 21 December 2007 05:25:00 Zhang Le wrote:
>> The question is really simple.
>> Whether we should have two different place to define EAPI?
> 
> We need two places because it wasn't implemented properly in the first place 
> and we want to retain backwards compatibility for people who use old versions 
> of portage. The whole point is to keep a sane upgrade path available 
> indefinitely for people with old versions of portage.

Thanks, now I understand this.
However, in the first draft the majority part of the glep talks about how to
decide EAPI value, which could make others misunderstand the real point behind
it. It should be made more clear in the first place, fortunately peper has
done that in the new draft of glep-55.
BTW, thanks to peper for drafting this glep!

However, this doesn't mean I have wholehearted accept this glep. This just
means if we ever decided we need ".ebuild-1" suffix, then surely we need such
an agreement on how to decide EAPI value.

> 
>> Proponents are trying to prove that we should at least need it be in file
>> name.
> 
> We need the file name to change because otherwise old versions of portage will 
> try to source the ebuild when the EAPI is unknown. This either blocks new 
> useful features that will make old versions of portage fail to source them or 
> results in more bug reports with zillions of dupes (like the bugs in [1]) 
> because people with ancient versions of portage feel the need to report bug 
> reports when portage fails after a sync.

I think we can educate our user about what is really going on and how to sovle
this problem (upgrade PM), by GWN/NEWs on front page/IRC topics/Forums stick
threads and so no.

> At the very least it means waiting for a year between a release with a version 
> of portage that supports this and an EAPI that takes advantage of it. So now 
> that leaves the question whether we want to change the file name once and 
> hope that we won't need to do it again or whether we want to use the 
> technically more flexible way where the file name changes whenever a new EAPI 
> gets agreed upon.

This is another thing needed to be sorted out before we decide to take this
suffix approach.

> 
> Or alternatively whether we want to limit ourselves by using an inferior 
> solution that limits or delays progress considerably and results in more bug 
> reports with zillions of dupes...

Honestly I really don't think our progress would be delayed in any way. The
argument to which other approach would delay our progress is that we need to
wait people to upgrade their PM. (If this assertion is wrong please ignore th
e following sentence) But upgrading PM is very easy, we can use all the
channels we have to inform user to upgrade their PM. And people are themselves
doing this all the time.

BTW, if we decide to use .ebuild-1, will we provide a ebuild file for each
EAPI for a specific version of software?

I guess probably not, coz that is a huge waste of time and energy. If this is
the case, then presumably we only provide new EAPI ebuild for new versions.

If a user want to use the new version, he *has* to upgrade his PM so that it
could support the new EAPI.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

On Sat, 22 Dec 2007 16:47:53 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> BTW, if we decide to use .ebuild-1, will we provide a ebuild file for
> each EAPI for a specific version of software?

The GLEP covers this. There's no sensible way of doing so.

> I guess probably not, coz that is a huge waste of time and energy. If
> this is the case, then presumably we only provide new EAPI ebuild for
> new versions.
> 
> If a user want to use the new version, he *has* to upgrade his PM so
> that it could support the new EAPI.

Yes, users will have to upgrade at some point. However, EAPI allows
them to upgrade in a graceful manner, without stopping the tree from
using new features, and without forcing a mass upgrade at any given
time.

(And yes, we have to be careful with the ebuilds for package managers
and some of their direct deps. But that's a very small part of the
tree.)

-- 
Ciaran McCreesh
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Simon Cooper]

As one of those 'users' (an AT actually), I would find having the eapi
in the filename quite annoying - especially having several ebuilds in
the tree that differ _only_ in their eapi number (and doing different
things). It just Seems Wrong - nearly all binary files do
versioning/format information inside the files, and one of the main
things I like in unix is that file format is *independant* of what you
actually name it (a text file can be named *.wibble, or even have no
extension at all and nothing will break).
Filenames are generally quite mutable - changing the filename is just a
single 'mv', whereas if you need to edit the file to change the type
that generally requires more effort, you need to think more about what
you're doing, and so theres less chance to break stuff (a eapi-1 file
accidentally gets moved to eapi-2, lots of stuff breaks, whereas if its
in the file you notice you need to edit it to actually make it eapi-2
compliant)

And please, please, don't base the decision on who can shout loudest or
longest. Think through each option (filename, inside file, metadata,
Manifest, directories, seperate db, ...) logically, weigh the pros and
cons, and decide on the one that would best fit gentoo on technical
grounds, not just on the one backed by the most vocal people. If you
make the wrong decision it could seriously screw gentoo over and make it
very painful in the future
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]

Simon Cooper wrote:
> nearly all binary files do versioning/format information inside the
> files

Think of different EAPIs as different set of rules for the ebuild
contents. If you accept this, you can easily define "new EAPI" as a "new
format for ebuilds". It's nice that current EAPI "1" is backwards
compatible with the default one, but nobody can guarantee that for
future EAPIs. And this is what this thread is about.

So, now if it is a different format, it is perfectly reasonable to
invent another extension for it, isn't it?

> and one of the main things I like in unix is that file format is
> *independant* of what you actually name it (a text file can be named
> *.wibble, or even have no extension at all and nothing will break).

On the contrary, if you rename an ebuild, it doesn't work.

> Filenames are generally quite mutable - changing the filename is just a
> single 'mv'

Only root can mess with files in my $PORTDIR. If you're working as root,
you should better pay attention before you move files around.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

On Sat, 22 Dec 2007 09:53:48 +0000
Simon Cooper <thecoop@runbox.com> wrote:
> As one of those 'users' (an AT actually), I would find having the eapi
> in the filename quite annoying - especially having several ebuilds in
> the tree that differ _only_ in their eapi number (and doing different
> things). It just Seems Wrong

Which is why the GLEP disallows it...

> Filenames are generally quite mutable - changing the filename is just
> a single 'mv', whereas if you need to edit the file to change the type
> that generally requires more effort, you need to think more about what
> you're doing, and so theres less chance to break stuff (a eapi-1 file
> accidentally gets moved to eapi-2, lots of stuff breaks, whereas if
> its in the file you notice you need to edit it to actually make it
> eapi-2 compliant)

I suggest you try using gcc to compile a C++ file with a .c file
extension...

> And please, please, don't base the decision on who can shout loudest
> or longest. Think through each option (filename, inside file,
> metadata, Manifest, directories, seperate db, ...) logically, weigh
> the pros and cons, and decide on the one that would best fit gentoo
> on technical grounds, not just on the one backed by the most vocal
> people. If you make the wrong decision it could seriously screw
> gentoo over and make it very painful in the future

Oh, we did all that long before the GLEP was written. The filename
solution is by far the best -- it's the only one that hasn't had any
technical objections raised to it.

-- 
Ciaran McCreesh
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Thomas de Grenier de Latour]

On 2007/12/22, Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> The filename solution is by far the best -- it's the only one that
> hasn't had any technical objections raised to it.

And can you remind us what technical objection, if any, has been raised
against the "EAPI set in contents with enough syntaxic restrictions to
allow its extraction without sourcing, and the files names extension
changing only if this rules have to change" alternative?

It's a bit annoying to see EAPI-in-contents solutions bashed everywhere
in this thread under the pretext of backward or forward compatibility,
whereas this points has been adressed very early in the discussion.

So, once more to make it clear: yes, the current ".ebuild" extension
would have to change into ".something" if we want to introduce such a
solution without waiting N months.  The difference with ".ebuild-$EAPI"
being that ".something" would then stay unchanged for numerous later
EAPIs (until some unlikely conditions are met, like a switch away from
Bash format).

-- 
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]

On Sat, 22 Dec 2007 16:23:13 +0100
Thomas de Grenier de Latour <degrenier@easyconnect.fr> wrote:
> On 2007/12/22, Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk>
> wrote:
> > The filename solution is by far the best -- it's the only one that
> > hasn't had any technical objections raised to it.
> 
> And can you remind us what technical objection, if any, has been
> raised against the "EAPI set in contents with enough syntaxic
> restrictions to allow its extraction without sourcing, and the files
> names extension changing only if this rules have to change"
> alternative?

a) It's a massive restriction on what future ebuilds can do.
b) It's a massive restriction on what current ebuilds can do.
c) It's an extremely bizarre restriction, the likes of which do not
currently exist, that will confuse the hell out of all the people that
don't realise that such a restriction exists.
d) It introduces a new prepass parse layer to an already complex
process.
e) The Portage guys said no to it.

> So, once more to make it clear: yes, the current ".ebuild" extension
> would have to change into ".something" if we want to introduce such a
> solution without waiting N months.  The difference with
> ".ebuild-$EAPI" being that ".something" would then stay unchanged for
> numerous later EAPIs

You keep saying that like *.ebuild-3 and *.ebuild-4 are massively
different. They're not. They're the same extension, decorated slightly
differently.

> (until some unlikely conditions are met, like a switch away from Bash
> format).

Or until we do something about eclasses and EAPIs, or until we do
something about storing metadata outside of the ebuilds themselves...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Thomas de Grenier de Latour]

On 2007/12/23, Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> a) It's a massive restriction on what future ebuilds can do.

 - it handles a reasonnable range of likely future EAPIs,
 - it includes the "extension changes when the way to extract EAPI
has to change" to avoid bounding future EAPIs to this range.

> b) It's a massive restriction on what current ebuilds can do.

Current ebuilds are the one with the ".ebuild" extension.  I'm not
proposing any change to the way they are handled.  

Now, if you mean that there are some stuffs allowed in ".ebuild" files
which would no more be allowed in the ".something" files, then yes: it
introduces some restrictions on how the EAPI is declared.  That's how
it works.  It has yet to be shown that this restrictions fordbids
anything else than some pointless code (like setting EAPI depending on
$PV), and furthermore that this code would, at the contrary, play well
with the GLEP 55 approach (obviously not the case with the previous
pointless example).

> c) It's an extremely bizarre restriction, the likes of which do not
> currently exist, that will confuse the hell out of all the people that
> don't realise that such a restriction exists.

Devs are already used to follow numerous conventions in the way they
format their ebuilds.  While this restriction is more than a
convention, I assume that's how it will be followed by many people:
just doing things the way they are in "skel.something". And for those
who happen to break the rule because they edited a ".something" file
without knowing what it was, they would learn as soon as they test/use
their file (no need to wait for the repoman step, it would be checked
whenever the ebuild is sourced).

> d) It introduces a new prepass parse layer to an already complex
> process.

Both solutions add some new steps to this process, and it doesn't look
to me like there's a significant difference beetween their respective
added complexity.  That said, you're the PM dev here, not me, so if you
confirm that implementation of an in-contents solution is significantly
harder, then i will accept the argument.

> e) The Portage guys said no to it.

When/where?  I've only seen Marius commenting here, but not on that
aspect.  Also, i've read this 2005 "EBUILD_FORMAT" discussion that Steve
Long has pointed [1], where Brian was against non-Bash parsing, but:
 - he was against changing files extension too,
 - the flaws in the EAPI system designed at this time is what led to
rethinking it now.

If i've missed something since then (and that's likely), could you
give me a pointer to the archives? Thanks.
 
[1] http://thread.gmane.org/gmane.linux.gentoo.devel/29512

> You keep saying that like *.ebuild-3 and *.ebuild-4 are massively
> different. They're not. They're the same extension, decorated slightly
> differently.

To me they look different enough that it's worth avoiding them if
possible (especialy considering the decoration is not just an
integer).  I absolutly agree that it's a futile and subjective
objection to GLEP 55, but so far, and until you answer to what i've
left open above, it's the only aspect on which i can think one solution
is better than the other.
 
> > (until some unlikely conditions are met, like a switch away from
> > Bash format).
> 
> Or until we do something about eclasses and EAPIs,

If you're not more specific about this "something", it's hard to say
what solution will handle it best.  
For example, it could be nice that some ebuilds which are just
instanciation of an eclass (like the vim-spell-* ones) let their eclass
decide what EAPI it needs.  That's something which could be handled
nicely by a backward-compatible extension of the EAPI-in-contents
approach: 
  # Copyright...
  eapi inherited:vim-spell-2
  VIM_SPELL_LANGUAGE="French"
  inherit vim-spell-2
(the "-2" here is not a specific EAPI, it's just that the "vim-spell"
eclass already exists and that it would not be a good idea to apply the
needed changes to it)
PMs which know how to handle such redirection would then go look for
an EAPI declared in the eclass before sourcing the whole thing. PMs
which don't yet would see it as an unsupported EAPI and stop there.

My point here is that the in-contents alternative is just a syntaxic
rule which defines a first-pass extraction of a value from an ebuild
file (as opposed to an ebuild file name extension).  How it is then
used (what the "eapi" function does, if anything, or whether this
value is the definitive EAPI, or how EAPI vs. eclasses is handled,
etc.) can be subject to future changes depending on this value. That's
part of why this solution is not more restrictive than the file name
extension approach.

> or until we do something about storing metadata outside of the ebuilds
> themselves...

  # Copyright...
  eapi from-external-metadatas
  ...

I agree there's an unecessary performance impact on doing that though,
so you're right that it's a case where changing the file extension
would be better. The EAPI declaration would be moved together with the
other metadatas, and its a whole new family of EAPIs which would fall
under this single new file name extension.

-- 
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 4706 bytes --]

On Sun, 23 Dec 2007 14:54:16 +0100
Thomas de Grenier de Latour <degrenier@easyconnect.fr> wrote:
> On 2007/12/23, Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk>
> wrote:
> > a) It's a massive restriction on what future ebuilds can do.
> 
>  - it handles a reasonnable range of likely future EAPIs,

It doesn't, though. For example, any good solution to the current eclass
EAPI issues is likely to break it.

>  - it includes the "extension changes when the way to extract EAPI
> has to change" to avoid bounding future EAPIs to this range.

Which we'll need to take anyway at some point.

> > c) It's an extremely bizarre restriction, the likes of which do not
> > currently exist, that will confuse the hell out of all the people
> > that don't realise that such a restriction exists.
> 
> Devs are already used to follow numerous conventions in the way they
> format their ebuilds.

And they already arbitrarily don't follow them. We get people screwing
up whitespace and brackets in dep strings, for example (Portage doesn't
error check these very well).

> > d) It introduces a new prepass parse layer to an already complex
> > process.
> 
> Both solutions add some new steps to this process, and it doesn't look
> to me like there's a significant difference beetween their respective
> added complexity.  That said, you're the PM dev here, not me, so if
> you confirm that implementation of an in-contents solution is
> significantly harder, then i will accept the argument.

It's not harder (assuming the syntax is well defined -- single, double
or no quotes? export? leading whitespace? is it the first or the last
match of EAPI="" that's taken?). It's just messy, because we'd have to
deal with stupid cases like:

DESCRPTION="Config file to make Paludis support
EAPI='4' packages"

EAPI="1"
  export   EAPI=2

src_compile() {
    cat <<END > somefile
EAPI=3
END
}

> > e) The Portage guys said no to it.
> 
> When/where?  I've only seen Marius commenting here, but not on that
> aspect.  Also, i've read this 2005 "EBUILD_FORMAT" discussion that
> Steve Long has pointed [1], where Brian was against non-Bash parsing,
> but:
>  - he was against changing files extension too,
>  - the flaws in the EAPI system designed at this time is what led to
> rethinking it now.
> 
> If i've missed something since then (and that's likely), could you
> give me a pointer to the archives? Thanks.

A while after that Brian and I had a huge lengthy argument on IRC about
it. I don't have IRC logs that far back, which is kind of a shame
because we covered pretty much all of the things that people are
moaning about now...

(And you'd also see the highly silly political reasons that lead to
*.ebuild* not being adopted straight off.)

> > > (until some unlikely conditions are met, like a switch away from
> > > Bash format).
> > 
> > Or until we do something about eclasses and EAPIs,
> 
> If you're not more specific about this "something", it's hard to say
> what solution will handle it best.  

If I had a perfect solution to the eclass problem, I'd've posted it
ages ago... But it's fairly likely that a good solution will require
considerably more flexibility than a simple static value in an ebuild
file.

> My point here is that the in-contents alternative is just a syntaxic
> rule which defines a first-pass extraction of a value from an ebuild
> file (as opposed to an ebuild file name extension).  How it is then
> used (what the "eapi" function does, if anything, or whether this
> value is the definitive EAPI, or how EAPI vs. eclasses is handled,
> etc.) can be subject to future changes depending on this value. That's
> part of why this solution is not more restrictive than the file name
> extension approach.

But then you get the highly weird result of setting, say, EAPI="4" in
the ebuild but the c/p-v actually having EAPI="3" because of weird hard
to see behind the scenes eclass voodoo. That's equivalent to the "using
the wrong file extension and then overriding with a variable"
situation, except that you're effectively requiring it for future
changes rather than making it something that's a big flashy warning.

(From a technical perspective, changing EAPI mid-source is a massive
pain in the ass. EAPI pretty much has to be able to tinker with PATH
and friends, and there's no sane way of modifying variables as soon as
another variable changes. For example, and not saying that this
specific case is desirable, EAPI foo could require that the first 'sed'
in PATH be GNU sed, whilst EAPI bar could require that it be the normal
system sed.)

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Steve Long]

Ciaran McCreesh wrote:
>> > c) It's an extremely bizarre restriction, the likes of which do not
>> > currently exist, that will confuse the hell out of all the people
>> > that don't realise that such a restriction exists.
>>
I don't think it's that hard to understand "You can only set EAPI *once* in
your ebuild." Are you really saying devs won't get that?

Who are these mythical "people"? Devs take a quiz: the EAPI setting
restrictions can easily be added to it, as well as being documented
elsewhere.

That would of course have to be done doubly so for your GLEP, which imposes
a much more bizarre restriction: that the EAPI must go in the filename.

>> Devs are already used to follow numerous conventions in the way they
>> format their ebuilds.
> 
> And they already arbitrarily don't follow them. We get people screwing
> up whitespace and brackets in dep strings, for example (Portage doesn't
> error check these very well).
>
Odd: I found repoman very fussy about those. Leaving the digs at portage
aside, that's what the new commit reviews are about.

>> > d) It introduces a new prepass parse layer to an already complex
>> > process.
>> 
>> Both solutions add some new steps to this process, and it doesn't look
>> to me like there's a significant difference beetween their respective
>> added complexity.  That said, you're the PM dev here, not me, so if
>> you confirm that implementation of an in-contents solution is
>> significantly harder, then i will accept the argument.
> 
> It's not harder (assuming the syntax is well defined -- single, double
> or no quotes? export? leading whitespace? is it the first or the last
> match of EAPI="" that's taken?). It's just messy, because we'd have to
> deal with stupid cases like:
> 
> DESCRPTION="Config file to make Paludis support
> EAPI='4' packages"
>
Wow, yet another contrived b0rkage. You really don't have a very high
opinion of Gentoo devs, do you?

> EAPI="1"
>   export   EAPI=2
> 
> src_compile() {
>     cat <<END > somefile
> EAPI=3
> END
> }
>
All those would be dealt with by the well-defined syntax. I'd start with:
EAPI="foo" on its own on a line. The first setting is taken.

>> > e) The Portage guys said no to it.
>> 
>> When/where?  I've only seen Marius commenting here, but not on that
>> aspect.  Also, i've read this 2005 "EBUILD_FORMAT" discussion that
>> Steve Long has pointed [1], where Brian was against non-Bash parsing,
>> but:
>>  - he was against changing files extension too,
>>  - the flaws in the EAPI system designed at this time is what led to
>> rethinking it now.
>> 
>> If i've missed something since then (and that's likely), could you
>> give me a pointer to the archives? Thanks.
> 
> A while after that Brian and I had a huge lengthy argument on IRC about
> it. I don't have IRC logs that far back, which is kind of a shame
> because we covered pretty much all of the things that people are
> moaning about now...
>
Somehow I'm not reading "Brian and I agreed that.." and it concerns me that
we haven't so far had portage and pkgcore devs chiming in that your GLEP is
just what they want as the solution to several issues, meriting the work
required to change over, and the future hackiness and restrictions it
imposes.

>> My point here is that the in-contents alternative is just a syntaxic
>> rule which defines a first-pass extraction of a value from an ebuild
>> file (as opposed to an ebuild file name extension).  How it is then
>> used (what the "eapi" function does, if anything, or whether this
>> value is the definitive EAPI, or how EAPI vs. eclasses is handled,
>> etc.) can be subject to future changes depending on this value. That's
>> part of why this solution is not more restrictive than the file name
>> extension approach.
> 
> But then you get the highly weird result of setting, say, EAPI="4" in
> the ebuild but the c/p-v actually having EAPI="3" because of weird hard
> to see behind the scenes eclass voodoo.
That sounds like a borked package manager, and something which should not be
allowed per the spec. If an ebuild author sets EAPI that's what the
metadata EAPI must reflect.

> That's equivalent to the "using 
> the wrong file extension and then overriding with a variable"
> situation, except that you're effectively requiring it for future
> changes rather than making it something that's a big flashy warning.
>
Or you're just contriving examples.
 
> (From a technical perspective, changing EAPI mid-source is a massive
> pain in the ass. EAPI pretty much has to be able to tinker with PATH
> and friends, and there's no sane way of modifying variables as soon as
> another variable changes. 
It's up to the eclass/ebuild author to deal with the consequences of code
they write. In the same light, it's up to the PM devs to ensure that the
EAPIs they support work correctly.

> For example, and not saying that this 
> specific case is desirable, EAPI foo could require that the first 'sed'
> in PATH be GNU sed, whilst EAPI bar could require that it be the normal
> system sed.)
> 
If you could come up with a more cogent example (that actually poses a
technical challenge) perhaps your peers can help you with the difficulties
you are having. That's what a dev mailing list is for.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> I'm guessing there're lots of people moaning because they think they
> understand filenames and can therefore comment. Unfortunately, most of
> those people don't understand the metadata generation process, and
> therefore can't comment usefully...

So please make those people understand, so they can comment usefully.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Piotr Jaroszyński]

On Thursday 20 of December 2007 19:29:22 Zhang Le wrote:
> So please make those people understand, so they can comment usefully.

Are we in the elementary school or something? This is really getting 
ridiculous.

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Piotr Jaroszyński wrote:
> On Thursday 20 of December 2007 19:29:22 Zhang Le wrote:
>> So please make those people understand, so they can comment usefully.
> 
> Are we in the elementary school or something? This is really getting 
> ridiculous.
> 

ietf.org Are they ridiculous?


lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On Sat, 22 Dec 2007 04:19:45 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Piotr Jaroszyński wrote:
> > On Thursday 20 of December 2007 19:29:22 Zhang Le wrote:
> >> So please make those people understand, so they can comment
> >> usefully.
> > 
> > Are we in the elementary school or something? This is really
> > getting ridiculous.
> 
> ietf.org Are they ridiculous?

Do you see them explaining what TCP is in great detail in every single
publication that mentions TCP?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> posted
20071222071328.72f16140@blueyonder.co.uk, excerpted below, on  Sat, 22 Dec
2007 07:13:28 +0000:

> On Sat, 22 Dec 2007 04:19:45 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Piotr Jaroszyński wrote:
>> > On Thursday 20 of December 2007 19:29:22 Zhang Le wrote:
>> >> So please make those people understand, so they can comment
>> >> usefully.
>> > 
>> > Are we in the elementary school or something? This is really getting
>> > ridiculous.
>> 
>> ietf.org Are they ridiculous?
> 
> Do you see them explaining what TCP is in great detail in every single
> publication that mentions TCP?

No, but ietf.org /does/ document what TCP is, and /not/ just in code 
either, so it's there for folks that need it.

I actually thought the point was pretty effective, given what it was in 
reply to.  If it were me the elementary school reply was made to, I'd 
have felt it within my rights to ask for an apology.  I therefore 
considered the ietf remark a rather clever reply to the innuendo, making 
the point delicately, while avoiding the loss of face challenge asking 
for an apology presents.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Piotr Jaroszyński]

On Saturday 22 of December 2007 12:03:33 Duncan wrote:
> I actually thought the point was pretty effective, given what it was in
> reply to.  If it were me the elementary school reply was made to, I'd
> have felt it within my rights to ask for an apology.  I therefore
> considered the ietf remark a rather clever reply to the innuendo, making
> the point delicately, while avoiding the loss of face challenge asking
> for an apology presents.

How is it fair that some people do their own research and some ask to be 
educated and for the discussion to be delayed?

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

Piotr Jaroszyński <peper@gentoo.org> posted
200712221550.44258.peper@gentoo.org, excerpted below, on  Sat, 22 Dec 2007
15:50:43 +0100:

> On Saturday 22 of December 2007 12:03:33 Duncan wrote:
>> If it were me the elementary school reply was made to, I'd
>> have felt it within my rights to ask for an apology.  I therefore
>> considered the ietf remark a rather clever reply to the innuendo,
>> making the point delicately, while avoiding the loss of face challenge
>> asking for an apology presents.
> 
> How is it fair that some people do their own research and some ask to be
> educated and for the discussion to be delayed?

I wasn't arguing that such was "fair".  The world isn't "fair".

I /was/ arguing that (IMO) the elementary school comment was out of line, 
and that had it been made to me, I'd have considered asking for an 
apology.  Instead, simply (re)stating that it's not something that can be 
easily explained and that it was your viewpoint that documentation wasn't 
needed (yes, I /know/ it's a restatement, there's no harm in showing a 
bit of exasperation in having to repeat it by mentioning the repeat), as 
Ciaran has been so patiently doing (thanks, Ciaran), would have (IMO) 
been more appropriate.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Ciaran McCreesh wrote:
> On Sat, 22 Dec 2007 04:19:45 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Piotr Jaroszyński wrote:
>>> On Thursday 20 of December 2007 19:29:22 Zhang Le wrote:
>>>> So please make those people understand, so they can comment
>>>> usefully.
>>> Are we in the elementary school or something? This is really
>>> getting ridiculous.
>> ietf.org Are they ridiculous?
> 
> Do you see them explaining what TCP is in great detail in every single
> publication that mentions TCP?
> 

usually pointing rfc793 in the right reference section and having an
xref pointing it directly embedded on the text referencing it.

So, yes.

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Jeroen Roovers]

On Fri, 21 Dec 2007 13:34:17 +0100
Piotr Jaroszyński <peper@gentoo.org> wrote:

> On Thursday 20 of December 2007 19:29:22 Zhang Le wrote:
> > So please make those people understand, so they can comment
> > usefully.
> 
> Are we in the elementary school or something? 

Yes, for all intents and purposes, assume your readership is in
elementary school. They're certainly not dump, maybe just ignorant, and
whatever you're trying to achieve is coming their way, so you'd better
have them on your side.


Kind regards,
     JeR
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Piotr Jaroszyński wrote:
> On Thursday 20 of December 2007 19:29:22 Zhang Le wrote:
>> So please make those people understand, so they can comment usefully.
> 
> Are we in the elementary school or something? This is really getting 
> ridiculous.

IMHO, what is more ridiculous is keeping ask other to be quiet in a discussion
  which is supposed to be open to everyone who cares about it.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

On Sat, 22 Dec 2007 16:09:27 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> IMHO, what is more ridiculous is keeping ask other to be quiet in a
> discussion which is supposed to be open to everyone who cares about
> it.

It's open to anyone who cares about it and is knowledgeable enough to
provide informed commentary. Anything else is just noise.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Sat, 22 Dec 2007 16:09:27 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>> IMHO, what is more ridiculous is keeping ask other to be quiet in a
>> discussion which is supposed to be open to everyone who cares about
>> it.
> 
> It's open to anyone who cares about it and is knowledgeable enough to
> provide informed commentary. Anything else is just noise.

At least not to tell others to be quiet.
It is a discussion after all.
We can let them become knowledgeable, at least we should try.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

On Sat, Dec 22, 2007 at 04:58:28PM +0800, Zhang Le wrote:
> Ciaran McCreesh wrote:
> > On Sat, 22 Dec 2007 16:09:27 +0800
> > Zhang Le <r0bertz@gentoo.org> wrote:
> >> IMHO, what is more ridiculous is keeping ask other to be quiet in a
> >> discussion which is supposed to be open to everyone who cares about
> >> it.
> > 
> > It's open to anyone who cares about it and is knowledgeable enough to
> > provide informed commentary. Anything else is just noise.
> 
> At least not to tell others to be quiet.
> It is a discussion after all.
> We can let them become knowledgeable, at least we should try.

Heh... unfortunately this is gentoo and this behaviour is tolerated. Try
to go with this same thing to the lkml[*1*]. Ask them to teach you C so
you can contribute with your opinion to every single patch and design
decision that is made. Then tell them they should teach you stuff about
OS design because you _are_entitled_ an opinion, then .... [then, sane
people see how this approach gets silly]

- ferdy

1 - And if you do so, please share Message-IDs, it'll make a great
laugh.

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Fernando J. Pereda wrote:
> On Sat, Dec 22, 2007 at 04:58:28PM +0800, Zhang Le wrote:
>> Ciaran McCreesh wrote:
>>> On Sat, 22 Dec 2007 16:09:27 +0800
>>> Zhang Le <r0bertz@gentoo.org> wrote:
>>>> IMHO, what is more ridiculous is keeping ask other to be quiet in a
>>>> discussion which is supposed to be open to everyone who cares about
>>>> it.
>>> It's open to anyone who cares about it and is knowledgeable enough to
>>> provide informed commentary. Anything else is just noise.
>> At least not to tell others to be quiet.
>> It is a discussion after all.
>> We can let them become knowledgeable, at least we should try.
> 
> Heh... unfortunately this is gentoo and this behaviour is tolerated. Try
> to go with this same thing to the lkml[*1*]. Ask them to teach you C so
> you can contribute with your opinion to every single patch and design
> decision that is made. Then tell them they should teach you stuff about
> OS design because you _are_entitled_ an opinion, then .... [then, sane
> people see how this approach gets silly]

I have mailed my patch to LKML. So I know the situation there.
Linux kernel community has a kernelnewbie mailing list. But we don't have one.
We don't even have enough docs to educate our future potential package manager
  maintainer. Note I am not blaming anyone there.
Let's start from ourselves.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

On Sun, Dec 23, 2007 at 01:14:46AM +0800, Zhang Le wrote:
> Fernando J. Pereda wrote:
> > On Sat, Dec 22, 2007 at 04:58:28PM +0800, Zhang Le wrote:
> >> Ciaran McCreesh wrote:
> >>> On Sat, 22 Dec 2007 16:09:27 +0800
> >>> Zhang Le <r0bertz@gentoo.org> wrote:
> >>>> IMHO, what is more ridiculous is keeping ask other to be quiet in a
> >>>> discussion which is supposed to be open to everyone who cares about
> >>>> it.
> >>> It's open to anyone who cares about it and is knowledgeable enough to
> >>> provide informed commentary. Anything else is just noise.
> >> At least not to tell others to be quiet.
> >> It is a discussion after all.
> >> We can let them become knowledgeable, at least we should try.
> > 
> > Heh... unfortunately this is gentoo and this behaviour is tolerated. Try
> > to go with this same thing to the lkml[*1*]. Ask them to teach you C so
> > you can contribute with your opinion to every single patch and design
> > decision that is made. Then tell them they should teach you stuff about
> > OS design because you _are_entitled_ an opinion, then .... [then, sane
> > people see how this approach gets silly]
> 
> I have mailed my patch to LKML. So I know the situation there.
> Linux kernel community has a kernelnewbie mailing list. But we don't have one.
> We don't even have enough docs to educate our future potential package manager
>   maintainer. Note I am not blaming anyone there.
> Let's start from ourselves.

Their docs are usually the source. Source that you still haven't studied
and keep moaning because we don't want to explain the process as if this
were primary school.

Go and read the source, study and understand it.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Fernando J. Pereda wrote:
> Their docs are usually the source. 

And files under Documentation
And they have a policy which requires them to write a doc for any new
feature/functionality to be accepted

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Piotr Jaroszyński]

On Saturday 22 of December 2007 09:09:27 Zhang Le wrote:
> Piotr Jaroszyński wrote:
> > On Thursday 20 of December 2007 19:29:22 Zhang Le wrote:
> >> So please make those people understand, so they can comment usefully.
> >
> > Are we in the elementary school or something? This is really getting
> > ridiculous.
>
> IMHO, what is more ridiculous is keeping ask other to be quiet in a
> discussion which is supposed to be open to everyone who cares about it.

I am not asking anyone to be quiet, but it's probably the best way to go if 
one doesn't care enough to do own research before asking to be educated.

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Wulf C. Krueger]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

> I DO understand.

You don't. The complete paragraph of yours shows you don't.

> But you're totally ignoring my point. So once again: You're trying to
> *SET* a standard here. There are lots of people telling you that they're
> not happy with the proposal to change the ebuild filename suffix.

Yes, indeed. They're not happy with it. That's about all most  
participants here have stated so far. There are two or three valid  
*technical* concerns and all the rest is basically noise.

> There seem to be less people opposed to having that ebuild format  
> restriction.

If this was only about the ebuild format restriction, I wouldn't even  
bother to write a single mail on this subject. It's much more  
important than that - the suggested GLEP would allow us to make use of  
new EAPI features much earlier than now and without causing major  
problems, I think.

Just this morning when I was reading my backlog in #-dev, I saw a  
discussion between between two devs that culminated in the following:

a> "So we can make use of this feature in about a year?"
b> "Yeah."

Are we Debian now? A new feature gets implemented (obviously because  
we *need* it) and we can make use of it in a *year*?

> So either choose the one that's accepted by the majority

The majority of devs doesn't even read here (not to speak of active  
participation).

-- 
Best regards, Wulf

[-- Attachment #2: PGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Wulf C. Krueger wrote:
> a> "So we can make use of this feature in about a year?"
> b> "Yeah."
> 
> Are we Debian now? A new feature gets implemented (obviously because we
> *need* it) and we can make use of it in a *year*?

What do we need so desperately?

> 
>> So either choose the one that's accepted by the majority
> 
> The majority of devs doesn't even read here (not to speak of active
> participation).

That says a lot in itself...


lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Rémi Cardona]

Luca Barbato a écrit :
> Wulf C. Krueger wrote:
>> a> "So we can make use of this feature in about a year?"
>> b> "Yeah."
>>
>> Are we Debian now? A new feature gets implemented (obviously because we
>> *need* it) and we can make use of it in a *year*?
> 
> What do we need so desperately?
> 
>>> So either choose the one that's accepted by the majority
>> The majority of devs doesn't even read here (not to speak of active
>> participation).
> 
> That says a lot in itself...

I'll speak up then :)

What I _really_ would like to see ASAP :

1) Dropping digest-* files for real (ie, not even having them on the
master rsync server and CVS)

2) Slotted deps (I had the feeling we were really close to having this a
while back, and then radio silence, maybe I missed the final announcement?)

3) USE-deps

As for the politics behind the naming of the EAPI, where it should be
placed in the ebuild, whether it should be in metadata.xml or in the
filename, I don't really care that much.

I'm much more interested in the 3 points above.

To all devs that will end up hacking on PMS and their respective PM :
don't let yourselves drown into loooooong term plans. Let's be an
opensource community with a "release early, release often" mentality.

Happy Holidays :)

Rémi
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Rémi Cardona wrote:
> I'll speak up then :)
> 
> What I _really_ would like to see ASAP :
> 
> 1) Dropping digest-* files for real (ie, not even having them on the
> master rsync server and CVS)
> 
> 2) Slotted deps (I had the feeling we were really close to having this a
> while back, and then radio silence, maybe I missed the final announcement?)
> 
> 3) USE-deps

Ok those interesting.

> As for the politics behind the naming of the EAPI, where it should be
> placed in the ebuild, whether it should be in metadata.xml or in the
> filename, I don't really care that much.

I'm thinking about having them embedded in the comment as first line as
something like

#!/usr/bin/env emerge --eapi $foo

or

# EAPI=$foo

IFF we want to consider single ebuilds, but since I don't like the
approach at all here another proposal:

I'd rather have a way to sync the tree so that:

- if your pm supports all the features you get the tree
- if your pm doesn't you get a minimal tree that let you update to the
newer one.

That means having a way to maintain a branch with just system and the
update path and have a way to put eapi versioning per tree.

This solves pretty much the root problems:

"do not have the package manager break on tree update"
and
"have a way to update the package manager from an ancient setup w/out
unpacking a newer stage on it (that could be yet another solution)"

Feel free to flame/decostruct this proposal as you please.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Doug Klima]

Luca Barbato wrote:
> Rémi Cardona wrote:
>   
>> I'll speak up then :)
>>
>> What I _really_ would like to see ASAP :
>>
>> 1) Dropping digest-* files for real (ie, not even having them on the
>> master rsync server and CVS)
>>     
Slated for after 2007.1 is released.

>> 2) Slotted deps (I had the feeling we were really close to having this a
>> while back, and then radio silence, maybe I missed the final announcement?)
>>     
You can already. Assuming you don't mind putting EAPI=1 inside of your
ebuilds.

>> 3) USE-deps
>>     
>
> Ok those interesting.
>
>   
>> As for the politics behind the naming of the EAPI, where it should be
>> placed in the ebuild, whether it should be in metadata.xml or in the
>> filename, I don't really care that much.
>>     
>
> I'm thinking about having them embedded in the comment as first line as
> something like
>
> #!/usr/bin/env emerge --eapi $foo
>
>   
I always wondered why we didn't put a shebang as such at the top of
ebuilds.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Michael Haubenwallner]

On Thu, 2007-12-20 at 17:22 +0100, Luca Barbato wrote:

> I'm thinking about having them embedded in the comment as first line as
> something like
> 
> #!/usr/bin/env emerge --eapi $foo

OT: It actually works adding this first line and do chmod +x foo.ebuild:

#! /usr/bin/env ebuild

Then you can do: ./foo.ebuild {digest,install,merge,whatever}

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Michael Haubenwallner wrote:
> On Thu, 2007-12-20 at 17:22 +0100, Luca Barbato wrote:
> 
>> I'm thinking about having them embedded in the comment as first line as
>> something like
>>
>> #!/usr/bin/env emerge --eapi $foo
> 
> OT: It actually works adding this first line and do chmod +x foo.ebuild:
> 
> #! /usr/bin/env ebuild
> 
> Then you can do: ./foo.ebuild {digest,install,merge,whatever}
> 

if we are lazy enough we could add this (and add --eapi foo support in
ebuild)

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Marius Mauch]

On Thu, 20 Dec 2007 17:22:22 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:

> I'm thinking about having them embedded in the comment as first line as
> something like
> 
> #!/usr/bin/env emerge --eapi $foo

Unfortunately the "emerge --eapi $foo" part would be passed as a single argument to /usr/bin/env, therefore can't work.

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Michael Haubenwallner]

On Thu, 2007-12-27 at 20:48 +0100, Marius Mauch wrote:
> On Thu, 20 Dec 2007 17:22:22 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
> 
> > I'm thinking about having them embedded in the comment as first line as
> > something like
> > 
> > #!/usr/bin/env emerge --eapi $foo
> 
> Unfortunately the "emerge --eapi $foo" part would be passed as a single argument to /usr/bin/env, therefore can't work.

This also could be done as (using 'ebuild' instead of 'emerge')

        #! /usr/bin/env ebuild.1

and PM could provide some 'ebuild.1' executable, at the bare mimimum
doing nothing but

        #! /bin/sh
        exec ebuild --eapi 1 "$@"

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

On Thu, 27 Dec 2007 21:28:41 +0100
Michael Haubenwallner <haubi@gentoo.org> wrote:
> This also could be done as (using 'ebuild' instead of 'emerge')
> 
>         #! /usr/bin/env ebuild.1
> 
> and PM could provide some 'ebuild.1' executable, at the bare mimimum
> doing nothing but
> 
>         #! /bin/sh
>         exec ebuild --eapi 1 "$@"

But *why*? We've finally almost gotten people away from installing
things using ebuild. Why on earth would we want to bring it back?

The correct way to install a package is through the nice, friendly,
mask checking, dependency resolving package manager frontend. There is
no correct action that can be taken when an ebuild is executed on its
own, so ebuilds shouldn't be executable on their own.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Thomas Pani]

Wulf C. Krueger wrote:
>> I DO understand.
> 
> You don't. The complete paragraph of yours shows you don't.
> 
Interesting, because my statement is the same (in meaning) that Ciaran
made two days ago. He stated it was "[...] another option. It's
considered less ideal [...]" ([1], in case you want to look it up)
>> But you're totally ignoring my point. So once again: You're trying to
>> *SET* a standard here. There are lots of people telling you that they're
>> not happy with the proposal to change the ebuild filename suffix.
> 
> Yes, indeed. They're not happy with it. That's about all most
> participants here have stated so far. There are two or three valid
> *technical* concerns and all the rest is basically noise.
> 
My concern is technical: Filenames are for identifying files uniquely.
An ebuild is uniquely identified by <cat>/<pn>-<pv>, so that's what it's
filename should be. Adding anything else to the filename will only
clutter the tree and lead to additional inconsitencies. Yes, you can
check for these using QA tools. But if it's not in the filename you
don't have to check.
If you say that package managers need the EAPI info so early that they
can't even read the first non-comment line of an ebuild that's fine. Go
and place it in the filename. But nobody had a *technical* argument why
that's the only possible solution so far. All I got was "you don't
understand all that fancy PM stuff".
>> There seem to be less people opposed to having that ebuild format
>> restriction.
> 
> If this was only about the ebuild format restriction, I wouldn't even
> bother to write a single mail on this subject. It's much more important
> than that - the suggested GLEP would allow us to make use of new EAPI
> features much earlier than now and without causing major problems, I think.
> 
> Just this morning when I was reading my backlog in #-dev, I saw a
> discussion between between two devs that culminated in the following:
> 
> a> "So we can make use of this feature in about a year?"
> b> "Yeah."
> 
> Are we Debian now? A new feature gets implemented (obviously because we
> *need* it) and we can make use of it in a *year*?
> 
No, we're not Debian, thank god. I thought the "wait 1+ year" policy
changed? Again citing Ciaran: "That was only the case because
previously, using new features that Portage didn't support would cause
horrible breakage. Now, instead, the ebuilds show up as being masked." [2]

Regards,
thomas

[1] http://archives.gentoo.org/gentoo-dev/msg_149455.xml
[2] http://archives.gentoo.org/gentoo-dev/msg_149031.xml
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Joe Peterson]

Thomas Pani wrote:
> My concern is technical: Filenames are for identifying files uniquely.
> An ebuild is uniquely identified by <cat>/<pn>-<pv>, so that's what it's
> filename should be. Adding anything else to the filename will only
> clutter the tree and lead to additional inconsitencies. Yes, you can
> check for these using QA tools. But if it's not in the filename you
> don't have to check.
> If you say that package managers need the EAPI info so early that they
> can't even read the first non-comment line of an ebuild that's fine. Go
> and place it in the filename. But nobody had a *technical* argument why
> that's the only possible solution so far. All I got was "you don't
> understand all that fancy PM stuff".

Good point.  First of all, and this is an architecture/design issue, the only
valid reason to put the EAPI in the filename is that is *belongs* there in
principal.  File extensions are for file types, not for info that really
should be in the file.  If the motivation for placing the info in the filename
(and worse, the *extension*) is that of performance, you should think twice
about putting it there.  If this is to address a technical problem, it should
be solved in a technical way.  The format of a filename should be determined
by policy, not technical implementation or convenience.

Technical reasons to avoid the filename are:

1) Increase of [needless] complexity in filenames/extensions (and only one
   example of the impact is that searching for ebuild files becomes less
   straightforward).
2) Having the same info in more than one place is bad (requiring extra repoman
   checks and the potential for ambiguity).  I don't care how many people
   say a) that this is not an issue or b) that it's "not a duplication",
   in every data system I've worked on, it has been a very bad idea to have
   more than one version of the same info that can get out of sync with each
   other.  Even if you take great care, I'd still always want to check both
   and not trust either version of the info blindly.  Caching or hashing is
   different (i.e. where the caching mechanism is robust), since the
   system itself keeps the cache up to date, and one version of the info
   is stricty derived from the other rather than both being the source.
3) It uses the extension in a way that goes against common use in computers.

Other reasons:

1) Littering the filename with this kind of stuff is potentially confusing do
   both devs and users - I know it's been stated that users don't care, but
   I don't think that's a good assumption.
2) It does not appear to be an elegant filename policy (and this can be
   considered technical as well), since elegance is something designed int
   good systems.
3) Assuming going this route is a mistake, it could be hard to reverse.

I just don't want to see something like this happen as a quick fix without
exploring all of the implications and how it effects what I consider a very
good system (portage/ebuilds) currently.  Also, it seems to me that there are
lots of other alternatives that have been discussed here (and some dismissed
rather quickly).  Portage and its policy are very core to Gentoo, and care
should be taken on this.

							-Joe

P.S.  I just joined Gentoo this year, and it is disheartening to see the
nastiness that some people are resorting to on this list.  I've never seen so
much anger and biting remarks in a project, and I can imagine it keeps some
from responding, which is ashame, since issues like this benefit from many
diverse viewpoints.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

On Thu, 20 Dec 2007 14:33:25 -0700
Joe Peterson <lavajoe@gentoo.org> wrote:
> P.S.  I just joined Gentoo this year, and it is disheartening to see
> the nastiness that some people are resorting to on this list.  I've
> never seen so much anger and biting remarks in a project, and I can
> imagine it keeps some from responding, which is ashame, since issues
> like this benefit from many diverse viewpoints.

No. Issues like this benefit from *well informed* diverse viewpoints.
They don't benefit from people running around going "waah! waah!
doesn't look nice! add format restrictions!" without understanding why
it's necessary.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Ciaran McCreesh wrote:
> No. Issues like this benefit from *well informed* diverse viewpoints.
> They don't benefit from people running around going "waah! waah!
> doesn't look nice! add format restrictions!" without understanding why
> it's necessary.

Putting a tag in the file name or at the to of the file as comment
(maybe using a #! line) is the same ...

We aren't on DOS we can use that nice tool called file and it's magic...

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 436 bytes --]

On Fri, 21 Dec 2007 03:17:12 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Putting a tag in the file name or at the to of the file as comment
> (maybe using a #! line) is the same ...

Three problems:

* We have to wait a year before we can use it.

* It's a format restriction. Some formats have to start with something
that's not #!.

* Ebuilds can't sensibly run in a Unix interpreterish way.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 03:17:12 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Putting a tag in the file name or at the to of the file as comment
>> (maybe using a #! line) is the same ...
> 
> Three problems:
> 
> * We have to wait a year before we can use it.

We have to wait till we got a new release and I hope it isn't 12months.

> * It's a format restriction. Some formats have to start with something
> that's not #!.

if the format doesn't allow anymore the #! comment for then it won't be
an ebuild anymore but an xbuild a ybuild a jbuild or whatever markup you
may propose as alternative to shell like syntax.

> * Ebuilds can't sensibly run in a Unix interpreterish way.

Would you mind articulate a bit?

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

On Fri, 21 Dec 2007 03:41:04 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Fri, 21 Dec 2007 03:17:12 +0100
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >> Putting a tag in the file name or at the to of the file as comment
> >> (maybe using a #! line) is the same ...
> > 
> > Three problems:
> > 
> > * We have to wait a year before we can use it.
> 
> We have to wait till we got a new release and I hope it isn't
> 12months.

No, you have to wait until it's safe to assume that everyone's using a
package manager that supports it.

> > * It's a format restriction. Some formats have to start with
> > something that's not #!.
> 
> if the format doesn't allow anymore the #! comment for then it won't
> be an ebuild anymore but an xbuild a ybuild a jbuild or whatever
> markup you may propose as alternative to shell like syntax.

Mmhmm. And then... Oh, we'd use a new file extension.

> > * Ebuilds can't sensibly run in a Unix interpreterish way.
> 
> Would you mind articulate a bit?

There's no sensible way for ./blah-1.23.ebuild to work. Ebuilds aren't
self-hosting, and a package manager isn't an interpreter, so the #!
model doesn't work very well.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

On Friday 21 December 2007 03:41:04 Luca Barbato wrote:
> > * We have to wait a year before we can use it.
>
> We have to wait till we got a new release and I hope it isn't 12months.

And then we have to wait till noone use a version of portage that sources the 
ebuild to get the EAPI. Unless we change the file name..

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Steve Long]

Bo Ørsted Andresen wrote:

> On Friday 21 December 2007 03:41:04 Luca Barbato wrote:
>> > * We have to wait a year before we can use it.
>>
>> We have to wait till we got a new release and I hope it isn't 12months.
> 
> And then we have to wait till noone use a version of portage that sources
> the ebuild to get the EAPI. Unless we change the file name..
> 
"We generally make sure that the tree is compatible with portage versions
released in the past six months, so if you don't have version released in
that timeframe it is possible that you won't be able to use the tree
anymore."[1]

What applications are so important that require this change in order to
work, that we have to go through the tool modifications now rather than
wait a few months and let the newer versions of portage deal with it,
without us having to make any changes at all?

After all we can use EAPI="1" already, and if the portage team want to put
more features in, they're at liberty to define EAPI="2" or any other.

It appears this is being rushed through: we can have some undefined new
features (well Paludis users can) now, if only we allow unbounded changes
to the filename suffix. That's not a good enough reason.

[1] http://www.gentoo.org/proj/en/portage/doc/common-problems.xml


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Bo Ørsted Andresen wrote:
> On Friday 21 December 2007 03:41:04 Luca Barbato wrote:
>>> * We have to wait a year before we can use it.
>> We have to wait till we got a new release and I hope it isn't 12months.
> 
> And then we have to wait till noone use a version of portage that sources the 
> ebuild to get the EAPI. Unless we change the file name..
> 

Not if we move the rsync path properly so

- older pm sync to a minimal try apt to upgrading portage and nothing else

- newer sync to the full tree now supporting the newer an better and
honey and milk eapi.

Still I think we should just postpone this discussion and get a 2008.0 out.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

On Sat, 22 Dec 2007 04:24:06 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Not if we move the rsync path properly so
> 
> - older pm sync to a minimal try apt to upgrading portage and nothing
> else
> 
> - newer sync to the full tree now supporting the newer an better and
> honey and milk eapi.

...and do it again every three months when a new EAPI comes along.
Great...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Ciaran McCreesh wrote:
> On Sat, 22 Dec 2007 04:24:06 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Not if we move the rsync path properly so
>>
>> - older pm sync to a minimal try apt to upgrading portage and nothing
>> else
>>
>> - newer sync to the full tree now supporting the newer an better and
>> honey and milk eapi.
> 
> ...and do it again every three months when a new EAPI comes along.
> Great...
> 

I don't see problems in doing that...

and NO, a new eapi must not appear every week.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Luca Barbato wrote:
> Still I think we should just postpone this discussion and get a 2008.0 out.

And postpone until some doc is out.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

On Sat, 22 Dec 2007 17:01:23 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> Luca Barbato wrote:
> > Still I think we should just postpone this discussion and get a
> > 2008.0 out.
> 
> And postpone until some doc is out.

There is absolutely no need for such a doc. You don't need to
understand every last detail of why things are the way they are in
order to use the new format. The only people who need to understand the
technicalities are those writing the package managers.

-- 
Ciaran McCreesh
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Sat, 22 Dec 2007 17:01:23 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>> Luca Barbato wrote:
>>> Still I think we should just postpone this discussion and get a
>>> 2008.0 out.
>> And postpone until some doc is out.
> 
> There is absolutely no need for such a doc. You don't need to
> understand every last detail of why things are the way they are in
> order to use the new format. The only people who need to understand the
> technicalities are those writing the package managers.

And what if that is my real intent?
No, just joking, but I am curious.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

On Sat, 22 Dec 2007 17:37:37 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Sat, 22 Dec 2007 17:01:23 +0800
> > Zhang Le <r0bertz@gentoo.org> wrote:
> >> Luca Barbato wrote:
> >>> Still I think we should just postpone this discussion and get a
> >>> 2008.0 out.
> >> And postpone until some doc is out.
> > 
> > There is absolutely no need for such a doc. You don't need to
> > understand every last detail of why things are the way they are in
> > order to use the new format. The only people who need to understand
> > the technicalities are those writing the package managers.
> 
> And what if that is my real intent?
> No, just joking, but I am curious.

Then you're up for a long hard "working it out for yourself and asking
lots of intelligent, well thought out questions (because any other kind
won't get answers) to people who've already done it" struggle. You have
the benefit of PMS to tell you more or less what the package manager /
ebuild API is, but you're on your own for the rest.

-- 
Ciaran McCreesh
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 03:17:12 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Putting a tag in the file name or at the to of the file as comment
>> (maybe using a #! line) is the same ...
> 
> Three problems:
> 
> * We have to wait a year before we can use it.

Why rush on this thing?
If the EAPI's feature is not freezing, I think we should do nothing but wait.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 334 bytes --]

On Fri, 21 Dec 2007 11:34:07 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> > * We have to wait a year before we can use it.
> 
> Why rush on this thing?
> If the EAPI's feature is not freezing, I think we should do nothing
> but wait.

There's no reason to make Gentoo go even longer without features.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 11:34:07 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>>> * We have to wait a year before we can use it.
>> Why rush on this thing?
>> If the EAPI's feature is not freezing, I think we should do nothing
>> but wait.
> 
> There's no reason to make Gentoo go even longer without features.

We can't take the risk of forking/splitting ourselves in exchange of only a
little features.
We are already very cool and unique and featured. Note I am not rejecting new
features. But we should know what price we will pay for the new features.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 395 bytes --]

On Fri, 21 Dec 2007 12:03:25 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> We can't take the risk of forking/splitting ourselves in exchange of
> only a little features.

EAPI introduces no risk of that. Quite the opposite -- it reduces it by
making it less likely that people will get sick of the inability to add
new features and go and do so elsewhere instead.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 12:03:25 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>> We can't take the risk of forking/splitting ourselves in exchange of
>> only a little features.
> 
> EAPI introduces no risk of that. Quite the opposite -- it reduces it by
> making it less likely that people will get sick of the inability to add
> new features and go and do so elsewhere instead.

Yes and no.
I agree with your above sentence.
But I am not sick of EAPI's. You see? I am sick of so *many* EAPI's.


-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

On Fri, 21 Dec 2007 12:27:31 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> But I am not sick of EAPI's. You see? I am sick of so *many* EAPI's.

What? All two of them that you need to know about, where the second
one is the first one with three new features?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 12:27:31 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>> But I am not sick of EAPI's. You see? I am sick of so *many* EAPI's.
> 
> What? All two of them that you need to know about, where the second
> one is the first one with three new features?

Sorry, I made you confused.
I was not talking about now, I am talking about the consequences of this glep.
At least we already have a EAPI 2 tracker in our bugzilla.
I am afraid we lose the control of EAPI development. or maybe I just over
reacted, but you get my point.
We need to make a formal development model and development cycle of EAPI.
We need to make sure all developers and as many users as possible to know it.

I have just created a page of EAPI on wikipedia, let's improve it together.
http://en.wikipedia.org/wiki/EAPI

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Zhang Le wrote:
> I have just created a page of EAPI on wikipedia, let's improve it together.
> http://en.wikipedia.org/wiki/EAPI

And later convert it to guidexml and put it on gentoo.org, of course.

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

Zhang Le wrote:
> Zhang Le wrote:
>> I have just created a page of EAPI on wikipedia, let's improve it together.
>> http://en.wikipedia.org/wiki/EAPI
> 
> And later convert it to guidexml and put it on gentoo.org, of course.

Wikipedia uses GFDL while we use CC-BY-SA, so no, you can't do that
before the Wikimedia Foundation manages to persuade FSF to change GFDL.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Jan Kundrát wrote:
> Zhang Le wrote:
>> Zhang Le wrote:
>>> I have just created a page of EAPI on wikipedia, let's improve it together.
>>> http://en.wikipedia.org/wiki/EAPI
>> And later convert it to guidexml and put it on gentoo.org, of course.
> 
> Wikipedia uses GFDL while we use CC-BY-SA, so no, you can't do that
> before the Wikimedia Foundation manages to persuade FSF to change GFDL.
> 

Sorry, I overlooked the license problem.
But anyway we need such a doc.
We can move to gentoo-wiki.com where the license by default is public domain.
http://gentoo-wiki.com/EAPI

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Josh Saddler]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 03:17:12 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Putting a tag in the file name or at the to of the file as comment
>> (maybe using a #! line) is the same ...

> * It's a format restriction. Some formats have to start with something
> that's not #!.

Who cares? Gentoo uses the ebuild/bash-with-shebang format. If you're
trying to shove in something outside of that, that would be a package
manager-specific format. Like XML-stuff (that can't include the shebang
or EAPI="foo" at the top) specifically for, say, Paludis.

But wait,

Ciaran McCreesh wrote:
>> robertz wrote:
>> especially PM specific EAPI. We can't have PM specific EAPI,
>> otherwise we are risking forking/splitting ourself.
>
> Package manager EAPIs don't belong in the main tree, but they have
> uses outside of it.

If it's package manager-specific, then it doesn't belong in the main
tree, as you stated. Would that include trying to push in the proposed
suffix changes? If they have uses outside of it, then consider
supporting it *only in that package manager*, rather than trying to
force it on what is largely an unreceptive Gentoo group. Near as I can
tell, it's only the Paludis folks that are interested in pushing this
GLEP through.

It doesn't seem like additional suffix flexibility is all that desirable
except to the folks who represent one package manager. And, well, one PM
does not make a specification. Mostly. Sorta. Occasionally. Sometimes.
You'd think.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

On Thu, 20 Dec 2007 20:46:35 -0800
Josh Saddler <nightmorph@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Fri, 21 Dec 2007 03:17:12 +0100
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >> Putting a tag in the file name or at the to of the file as comment
> >> (maybe using a #! line) is the same ...
> 
> > * It's a format restriction. Some formats have to start with
> > something that's not #!.
> 
> Who cares? Gentoo uses the ebuild/bash-with-shebang format. If you're
> trying to shove in something outside of that, that would be a package
> manager-specific format. Like XML-stuff (that can't include the
> shebang or EAPI="foo" at the top) specifically for, say, Paludis.

And that's the kind of thinking that landed Gentoo in the "unable to
add new features" camp for several years.

> If it's package manager-specific, then it doesn't belong in the main
> tree, as you stated. Would that include trying to push in the proposed
> suffix changes?

Uh, no. It's a GLEP so that everyone can do it.

> If they have uses outside of it, then consider supporting it *only
> in that package manager*, rather than trying to force it on what is
> largely an unreceptive Gentoo group.

Paludis has it already for other trees. We're trying to get Gentoo, and
all ebuild-using package managers, to start using it because it's a good
solution and solves several problems that Gentoo has currently.

> Near as I can tell, it's only the Paludis folks that are interested
> in pushing this GLEP through.

Have you tried asking the Portage developer?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Ciaran McCreesh wrote:
>> Near as I can tell, it's only the Paludis folks that are interested
>> in pushing this GLEP through.
> 
> Have you tried asking the Portage developer?
> 

yes, and I'm waiting for others' opinions too ^^;

Since seems that enough people are against this glep and many are
undecided I started polling around for alternatives...

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

On Fri, 21 Dec 2007 07:24:26 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Since seems that enough people are against this glep and many are
> undecided I started polling around for alternatives...

But there has yet to be a correct technical objection, nor a correct
alternative proposed, nor a demonstration of why the problems
discussed in the GLEP are safely ignorable...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 07:24:26 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Since seems that enough people are against this glep and many are
>> undecided I started polling around for alternatives...
> 
> But there has yet to be a correct technical objection, nor a correct
> alternative proposed, nor a demonstration of why the problems
> discussed in the GLEP are safely ignorable...

Well putting the eapi per tree/repo and provide a way to fetch directly
the tree a package manager can understand sounds pretty much a simpler
alternative.

Add that basically much of the discussion is founded on uncertain basis
since there isn't a document about what exactly eapi is supposed to be,
nor other details that you considered compulsory to get a clue about
what's being discussed, so there isn't quite a way to say what's good
and what isn't beside polling who is hacking package managers about
alternatives and have an idea of what the dev base likes better if there
are equivalent solutions.

and NO there isn't a compelling reason to do anything _real_soon_

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

On Fri, 21 Dec 2007 11:18:53 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Well putting the eapi per tree/repo and provide a way to fetch
> directly the tree a package manager can understand sounds pretty much
> a simpler alternative.

And it defeats the whole point of having EAPI at all.

> Add that basically much of the discussion is founded on uncertain
> basis since there isn't a document about what exactly eapi is
> supposed to be, nor other details that you considered compulsory to
> get a clue about what's being discussed, so there isn't quite a way
> to say what's good and what isn't beside polling who is hacking
> package managers about alternatives and have an idea of what the dev
> base likes better if there are equivalent solutions.

Then don't say anything. Leave the discussion to those who know what
the whole thing is about.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

On Friday 21 December 2007 05:46:35 Josh Saddler wrote:
> Who cares? Gentoo uses the ebuild/bash-with-shebang format. If you're
> trying to shove in something outside of that, that would be a package
> manager-specific format. Like XML-stuff (that can't include the shebang
> or EAPI="foo" at the top) specifically for, say, Paludis.

GLEP means Gentoo Linux Enhancement Proposal. It was proposed to enhance 
Gentoo... Paludis already supports this kind of thing for usage outside 
gentoo-x86. That has no relevance to Gentoo unless the GLEP gets approved...

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

On Thursday 20 December 2007 22:33:25 Joe Peterson wrote:
> Technical reasons to avoid the filename are:
>
> 2) Having the same info in more than one place is bad (requiring extra
> repoman checks and the potential for ambiguity).

As opposed to adding checks to make sure that obtaining the EAPI from the 
contents of the file doesn't require bash?

> 3) It uses the extension in a way that goes against common use in computers.

What? It uses the extension to determine the format of the contents?

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Joe Peterson]

Assuming that the file extension must change to prevent current PMs from
trying to parse new format ebuilds (and not require waiting a year or
more), I'd be a lot happier seeing it change *once* to a new fixed
extension, with the requirement that the new ebuilds are required to
contain within them them EAPI.  This should future-proof the system.

Preferably, shorten the extension and make a new standard.  I noticed
that ".eb" seems to be unused
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

On Fri, 21 Dec 2007 09:37:27 -0700
Joe Peterson <lavajoe@gentoo.org> wrote:
> Assuming that the file extension must change to prevent current PMs
> from trying to parse new format ebuilds (and not require waiting a
> year or more), I'd be a lot happier seeing it change *once* to a new
> fixed extension, with the requirement that the new ebuilds are
> required to contain within them them EAPI.  This should future-proof
> the system.

Only until another source-level change comes along, which will
hopefully be fairly soon -- eclasses need a good kick in the nuts, for
example, and that pretty much means a source-level break.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

On Thursday 20 December 2007 17:14:52 Thomas Pani wrote:
> > Are we Debian now? A new feature gets implemented (obviously because we
> > *need* it) and we can make use of it in a *year*?
>
> No, we're not Debian, thank god. I thought the "wait 1+ year" policy
> changed? Again citing Ciaran: "That was only the case because
> previously, using new features that Portage didn't support would cause
> horrible breakage. Now, instead, the ebuilds show up as being masked." [2]

It has changed as long as you don't introduce features that makes old versions 
of portage fail to source the ebuild. EAPI=1 didn't do that.

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Luca Barbato wrote:
> Before spending even more time on it, could we try to come up with a
> definition of what eapi is, which problem is trying to solve and put
> that somewhere that isn't a long thread or an handful of threads
> scattered across mailing lists.

I think we also need to know:
How many EAPI's do we have now?
Where is the detailed definition of those EAPI's?
How can we produce a new EAPI?

IMO, we can not have more than two EAPI's simultaneously.
The only situation in which we can have two EAPI is in the transition period
of those two EAPI's. And we should set a time constraint on the transition.
Other than that we can only have one working EAPI which all package managers
conforms to.

Otherwise, I think we may be risking forking the portage tree.


-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Santiago M. Mola]

On Dec 20, 2007 8:01 PM, Zhang Le <r0bertz@gentoo.org> wrote:
>
> How many EAPI's do we have now?

In Portage tree we have "0" (default) and "1". There are others in
external projects, for example "prefix" (in Gentoo/Alt:Prefix) or
"paludis-1" (used in paludis repositories).

> Where is the detailed definition of those EAPI's?

"0", "1" and any further official EAPI are defined in PMS. There's a
svn repository at http://svn.repogirl.net/pms

> How can we produce a new EAPI?

I can't tell you the exact process, but look at EAPI bug trackers or
search for bugs assigned to pms-bugs@gentoo.org. Also, search in
@-dev's archive.

>
> IMO, we can not have more than two EAPI's simultaneously.
> The only situation in which we can have two EAPI is in the transition period
> of those two EAPI's. And we should set a time constraint on the transition.
>

Quite the opposite. EAPI's are designed to live happily together in
the same repository. A current example: most (or lots...) ebuilds in
the tree don't need EAPI="1" and it's pointless to migrate all of
them. We can switch EAPI on an as needed basis.

> Other than that we can only have one working EAPI which all package managers
> conforms to.

Read above, and other discussions. That's also pointless because we
don't need to force all third party overlays to upgrade EAPI everytime
we have a new one...

-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: EAPI definition Was: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Markus Ullmann]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

Santiago M. Mola wrote:
> On Dec 20, 2007 8:01 PM, Zhang Le <r0bertz@gentoo.org> wrote:
>> Where is the detailed definition of those EAPI's?
> 
> "0", "1" and any further official EAPI are defined in PMS. There's a
> svn repository at http://svn.repogirl.net/pms

Erm no, PMS isn't officially until council made a decision on it (and
I'm not aware of one yet).
Currently "official" EAPIs are 0 and 1.

Greetz
-Jokey


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Re: EAPI definition Was: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Wulf C. Krueger]

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]

On Thursday, 20. December 2007 21:27:03 Markus Ullmann wrote:
> Erm no, PMS isn't officially until council made a decision on it (and
> I'm not aware of one yet).
> Currently "official" EAPIs are 0 and 1.

And EAPI-1 is defined where? :)

-- 
Best regards, Wulf

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Santiago M. Mola wrote:
> On Dec 20, 2007 8:01 PM, Zhang Le <r0bertz@gentoo.org> wrote:
>> How many EAPI's do we have now?
> 
> In Portage tree we have "0" (default) and "1". There are others in
> external projects, for example "prefix" (in Gentoo/Alt:Prefix) or
> "paludis-1" (used in paludis repositories).
> 
>> Where is the detailed definition of those EAPI's?
> 
> "0", "1" and any further official EAPI are defined in PMS. There's a
> svn repository at http://svn.repogirl.net/pms
> 
>> How can we produce a new EAPI?
> 
> I can't tell you the exact process, but look at EAPI bug trackers or
> search for bugs assigned to pms-bugs@gentoo.org. Also, search in
> @-dev's archive.

We should make a FAQ about all this.

> 
>> IMO, we can not have more than two EAPI's simultaneously.
>> The only situation in which we can have two EAPI is in the transition period
>> of those two EAPI's. And we should set a time constraint on the transition.
>>
> 
> Quite the opposite. EAPI's are designed to live happily together in
> the same repository. A current example: most (or lots...) ebuilds in
> the tree don't need EAPI="1" and it's pointless to migrate all of
> them. We can switch EAPI on an as needed basis.

But EAPI's can not always co-exist harmoniously.
What if a future EAPI come up with a totally new DEPENDENCY setting[1], which
is incompatible with existing ones.
I really don't see the necessity to have so many EAPI's, especially PM
specific EAPI. We can't have PM specific EAPI, otherwise we are risking
forking/splitting ourself.

[1] https://bugs.gentoo.org/show_bug.cgi?id=201499


-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

On Fri, 21 Dec 2007 11:23:08 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> > Quite the opposite. EAPI's are designed to live happily together in
> > the same repository. A current example: most (or lots...) ebuilds in
> > the tree don't need EAPI="1" and it's pointless to migrate all of
> > them. We can switch EAPI on an as needed basis.
> 
> But EAPI's can not always co-exist harmoniously.
> What if a future EAPI come up with a totally new DEPENDENCY
> setting[1], which is incompatible with existing ones.

DEPENDENCIES can exist in the same tree as *DEPEND. They can't exist
within the same ebuild, but that's OK because you can't mix EAPIs at
that level.

> I really don't see the necessity to have so many EAPI's

A new EAPI is needed for new features, so new EAPIs will be needed in
the future. Equally, migrating the whole tree at once to newer EAPIs is
a) a lot of unnecessary work, and b) unnecessarily irritating to people
using older package managers.

> especially PM specific EAPI. We can't have PM specific EAPI,
> otherwise we are risking forking/splitting ourself.

Package manager EAPIs don't belong in the main tree, but they have uses
outside of it.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 11:23:08 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
> 
>> I really don't see the necessity to have so many EAPI's
> 
> A new EAPI is needed for new features, so new EAPIs will be needed in
> the future. Equally, migrating the whole tree at once to newer EAPIs is
> a) a lot of unnecessary work, and b) unnecessarily irritating to people
> using older package managers.

I think we should first decide on how EAPI works.
This is also a prerequisite for this glep to be further discussed.
Just because we need a new feature, then we produce a new EAPI?
I think that is not feasible, and will confuse developers.

> 
>> especially PM specific EAPI. We can't have PM specific EAPI,
>> otherwise we are risking forking/splitting ourself.
> 
> Package manager EAPIs don't belong in the main tree, but they have uses
> outside of it.

Then would you please introduce how paludis-1 EAPI differs from official EAPI's?

-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

On Fri, 21 Dec 2007 12:15:10 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> I think we should first decide on how EAPI works.

That was decided a long time ago.

> Just because we need a new feature, then we produce a new EAPI?
> I think that is not feasible, and will confuse developers.

Uh... Yes. It's entirely feasible, it's how things work and it's an
entirely sensible model.

The *problem* is not EAPI itself. The problem is how EAPI is currently
specified by ebuilds. That's all the GLEP changes, and all it really
needs to change.

> >> especially PM specific EAPI. We can't have PM specific EAPI,
> >> otherwise we are risking forking/splitting ourself.
> > 
> > Package manager EAPIs don't belong in the main tree, but they have
> > uses outside of it.
> 
> Then would you please introduce how paludis-1 EAPI differs from
> official EAPI's?

It has a bunch of arbitrary, randomly changing features that I need
when doing test cases for functionality that isn't covered by any
official EAPI. For example, a long before EAPI 1 came along, Paludis
had slot dep support. In order to test slot deps, we needed an EAPI
that permitted them -- hence paludis-1.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: EAPI definition Was: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Duncan]

Zhang Le <r0bertz@gentoo.org> posted 476B3DCE.6080801@gentoo.org,
excerpted below, on  Fri, 21 Dec 2007 12:15:10 +0800:

> Ciaran McCreesh wrote:

>> Package manager EAPIs don't belong in the main tree, but they have uses
>> outside of it.
> 
> Then would you please introduce how paludis-1 EAPI differs from official
> EAPI's?

Agreed with Ciarn here.  Certain PMs, call them super-PMs if you will,  
wish to work with formats other than Gentoo formats, with an ultimate 
goal of working with distributions other than Gentoo.  If it's not for 
use in the main tree, how does it affect Gentoo, and if it doesn't affect 
Gentoo, how is it on topic here?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

On Thursday 20 December 2007 20:01:55 Zhang Le wrote:
> IMO, we can not have more than two EAPI's simultaneously.

That defeats the whole purpose of having EAPIs. Which is to keep a sane 
upgrade path...

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Bo Ørsted Andresen wrote:
> On Thursday 20 December 2007 20:01:55 Zhang Le wrote:
>> IMO, we can not have more than two EAPI's simultaneously.
> 
> That defeats the whole purpose of having EAPIs. Which is to keep a sane 
> upgrade path...

Upgrading happens between two versions.

When a new version comes out, we should educate developers about it and
encourage them to convert their ebuilds to use new EAPI.
When this finished, we can start upgrading to a more new version of EAPI.
IMHO, that should be the right way to go.
However, I think there is still devs don't know about EAPI-1.

If we allow multiple EAPI's to co-exist, do we need a upper limit on that
number? Or as many as someone likes? then our tree IMO will become a total
mess. People will not remember clearly differences between so many EAPI's.


-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

On Sat, 22 Dec 2007 17:49:32 +0800
Zhang Le <r0bertz@gentoo.org> wrote:
> When a new version comes out, we should educate developers about it
> and encourage them to convert their ebuilds to use new EAPI.

No, we shouldn't. People should use new EAPIs as necessary, not as soon
as possible.

> If we allow multiple EAPI's to co-exist, do we need a upper limit on
> that number?

No. Package managers have to support all EAPIs that have ever been
around anyway to deal with installed packages.

> Or as many as someone likes? then our tree IMO will become a total
> mess. People will not remember clearly differences between so many
> EAPI's.

They don't need to. They just need to be familiar with recent EAPIs.
The only people who have to keep track of all of them are the package
manager people.

-- 
Ciaran McCreesh
-- 
gentoo-dev@gentoo.org mailing list

Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Zhang Le]

Ciaran McCreesh wrote:
> On Sat, 22 Dec 2007 17:49:32 +0800
> Zhang Le <r0bertz@gentoo.org> wrote:
>> When a new version comes out, we should educate developers about it
>> and encourage them to convert their ebuilds to use new EAPI.
> 
> No, we shouldn't. People should use new EAPIs as necessary, not as soon
> as possible.

Then we should at least provide them a doc first and let them know when the
doc is already. So they can learn when they feel like they should learn.


-- 
Zhang Le, Robert
GPG key ID: 1E4E2973
Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Denis Dupeyron]

On Dec 20, 2007 1:38 AM, Donnie Berkholz <dberkholz@gentoo.org> wrote:
> Here's some other ideas for how to express EAPI. What if we:
[..]
> Stuck ranges into metadata.xml for which EAPIs applied?

This is the easiest and most reasonable solution I've heard so far.

Denis.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

On Wed, 19 Dec 2007 16:38:01 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> Here's some other ideas for how to express EAPI. What if we:
> 
> Used EAPI-named subdirectories instead of tagging it into the
> filename?

Performance hit, and otherwise equivalent to using suffixes.

> Used (and required) filesystem extended attributes?

Unportable, unsyncable and unmaintainable.

> Stuck ranges into metadata.xml for which EAPIs applied?

No package manager required information can be in XML format.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Donnie Berkholz]

On 08:29 Thu 20 Dec     , Ciaran McCreesh wrote:
> On Wed, 19 Dec 2007 16:38:01 -0800
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > Here's some other ideas for how to express EAPI. What if we:
> > 
> > Used EAPI-named subdirectories instead of tagging it into the
> > filename?
> 
> Performance hit, and otherwise equivalent to using suffixes.

Not quite so ugly-looking to my eyes.

> > Used (and required) filesystem extended attributes?
> 
> Unportable, unsyncable and unmaintainable.

Unportable to filesystems that don't support extended attributes isn't 
very interesting to me, unless they're common. Out of curiosity, do you 
know which ones that would be? Looking at my kernel config, ext3 and 
reiser explicitly support xattrs, and I see jfs and xfs have acls and 
security labels, which might be usable. Unsyncable would be a problem, 
so it's a good thing rsync has USE=xattr -- do the difficulties come in 
on the CVS side? Why do you say unmaintainable?

> > Stuck ranges into metadata.xml for which EAPIs applied?
> 
> No package manager required information can be in XML format.

Says who? Us. We can change that, if we decide it's the best answer. =)

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

Donnie Berkholz kirjoitti:
> On 08:29 Thu 20 Dec     , Ciaran McCreesh wrote:
>> On Wed, 19 Dec 2007 16:38:01 -0800
>> Donnie Berkholz <dberkholz@gentoo.org> wrote:
>>> Here's some other ideas for how to express EAPI. What if we:
>>>
>>> Used EAPI-named subdirectories instead of tagging it into the
>>> filename?
>> Performance hit, and otherwise equivalent to using suffixes.
> 
> Not quite so ugly-looking to my eyes.
> 
>>> Used (and required) filesystem extended attributes?
>> Unportable, unsyncable and unmaintainable.
> 
> Unportable to filesystems that don't support extended attributes isn't 
> very interesting to me, unless they're common. Out of curiosity, do you 
> know which ones that would be? Looking at my kernel config, ext3 and 
> reiser explicitly support xattrs, and I see jfs and xfs have acls and 
> security labels, which might be usable. Unsyncable would be a problem, 
> so it's a good thing rsync has USE=xattr -- do the difficulties come in 
> on the CVS side? Why do you say unmaintainable?
> 

Many users might have extended attributes support turned off in the kernel.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Josh Saddler]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

Petteri Räty wrote:
> Donnie Berkholz kirjoitti:
>> Unportable to filesystems that don't support extended attributes isn't 
>> very interesting to me, unless they're common. Out of curiosity, do you 
>> know which ones that would be? Looking at my kernel config, ext3 and 
>> reiser explicitly support xattrs, and I see jfs and xfs have acls and 
>> security labels, which might be usable. Unsyncable would be a problem, 
>> so it's a good thing rsync has USE=xattr -- do the difficulties come in 
>> on the CVS side? Why do you say unmaintainable?
>>
> 
> Many users might have extended attributes support turned off in the kernel.

/me raises hand. yup. don't use 'em. waste of kernel space.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

Donnie Berkholz wrote:
> Looking at my kernel config, ext3 and reiser explicitly support
> xattrs, and I see jfs and xfs have acls and security labels, which
> might be usable.

Extended attributes can be turned off during compile time for each
filesystem you mentioned. NFSv3 doesn't support them (yes, I do share
$PORTDIR). Also note that in some circumstances like when running in a
virtualized environment, imposing additional requirements on the kernel
might be problematic. It wouldn't be great to require extended
attributes for each and every Gentoo box...

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Donnie Berkholz]

On 10:43 Thu 20 Dec     , Jan Kundrát wrote:
> Donnie Berkholz wrote:
> > Looking at my kernel config, ext3 and reiser explicitly support
> > xattrs, and I see jfs and xfs have acls and security labels, which
> > might be usable.
> 
> Extended attributes can be turned off during compile time for each
> filesystem you mentioned.

And?

If you turn off features you need, things break. There's nothing new 
about that. If you disable ext3 support in your kernel, you can't mount 
an ext3 partition and you'll get an error during boot about not finding 
the root.

> NFSv3 doesn't support them (yes, I do share $PORTDIR).

While doing a search about this, I came across a page on the Beagle site 
describing how Beagle deals with a similar issue that says:

 "Extended attributes are used by Beagle to keep track of which files 
  have been indexed and which need to be re-indexed. There is a 
  sqlite-based fallback which is a bit slower, so it is recommended that 
  you do use extended attributes. ...

 "Your kernel will need support for extended attributes on the filesystem 
  you are indexing. If you are using XFS or JFS, extended attributes are 
  always enabled and you can skip this section and move on to Installing 
  prerequisites. For Reiser3, ext2 and ext3 filesystems, the default 
  kernel config does not enable the attributes. ...

 "Also note that neither Reiser4 nor NFS support extended attributes, so 
  the sqlite-based fallback will be used by default."

The idea of the sqlite-based fallback is what's interesting here.

> Also note that in some circumstances like when running in a
> virtualized environment, imposing additional requirements on the kernel
> might be problematic.

Why's that? Here's some performance tests from 3 years ago on a 2.6.10 
kernel that hopefully have improved in the meanwhile:

http://lwn.net/Articles/112566/

> It wouldn't be great to require extended attributes for each and every 
> Gentoo box...

Why not?

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

On Thursday 20 December 2007 11:09:44 Donnie Berkholz wrote:
> > > Looking at my kernel config, ext3 and reiser explicitly support
> > > xattrs, and I see jfs and xfs have acls and security labels, which
> > > might be usable.
[...]
> The idea of the sqlite-based fallback is what's interesting here.

I thought some of the other ideas were pretty bad... Guess I was wrong... This 
is the worst idea I have ever heard.

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Donnie Berkholz]

On 11:26 Thu 20 Dec     , Bo Ørsted Andresen wrote:
> On Thursday 20 December 2007 11:09:44 Donnie Berkholz wrote:
> > > > Looking at my kernel config, ext3 and reiser explicitly support 
> > > > xattrs, and I see jfs and xfs have acls and security labels, 
> > > > which might be usable.
> [...]
> > The idea of the sqlite-based fallback is what's interesting here.
> 
> I thought some of the other ideas were pretty bad... Guess I was 
> wrong... This is the worst idea I have ever heard.

<sarcasm>Thanks for your useful and detailed criticism.</sarcasm>

Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

Donnie Berkholz wrote:
> If you turn off features you need, things break. There's nothing new 
> about that. If you disable ext3 support in your kernel, you can't mount 
> an ext3 partition and you'll get an error during boot about not finding 
> the root.

I see your point, but extended attributes aren't as common as ext3, are
they. And stuff that got broken because Portage suddenly started to
require new features on the kernel side is bad.

> The idea of the sqlite-based fallback is what's interesting here.

If it is a fallback that must be supported (because of NFS), then there
isn't much point in using xattrs. What benefits do they provide? There's
no speed constraint here as we already cache metadata somewhere.

>> Also note that in some circumstances like when running in a
>> virtualized environment, imposing additional requirements on the kernel
>> might be problematic.
> 
> Why's that?

Things with Xen got better than they were, but I can imagine a situation
where some hosting provider offers their customers a virtual Xen box and
their kernel configuration doesn't include extended attributes. You
can't use your own kernel without access to dom0.

>> It wouldn't be great to require extended attributes for each and every 
>> Gentoo box...
> 
> Why not?

Because they aren't so common, NFS doesn't support them and we haven't
ever required them.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Wulf C. Krueger]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

>> Extended attributes can be turned off during compile time for each
>> filesystem you mentioned.
> If you turn off features you need, things break. There's nothing new
> about that. If you disable ext3 support in your kernel, you can't mount
> an ext3 partition and you'll get an error during boot about not finding
> the root.

What you're proposing, though, is *requiring* a feature most people  
don't even know about or use. Yes, if I want to boot from ext3, I'll  
need support for it in the kernel. That's a very fundamental  
assumption and one that even our most "challenged" users will  
understand.

Requiring extended attributes for the Portage tree is something  
completely different. There's simply no need to require additional  
features for something that can be done in the filename.

Is there any *technical* reason you object to the GLEP? Because your  
aesthetic sense may be commendable but I for one find the suggestion  
*beautifully* simple. :-)

Of course, taste can't be argued about (obviously I have an excellent  
taste and you don't! ;-) ) so I'd be really curious if there are  
technical reasons.

>> It wouldn't be great to require extended attributes for each and every
>> Gentoo box...
> Why not?

Because we shouldn't require stuff we don't *have* to.

-- 
Best regards, Wulf

[-- Attachment #2: PGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]

On Thu, 20 Dec 2007 01:19:46 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 08:29 Thu 20 Dec     , Ciaran McCreesh wrote:
> > On Wed, 19 Dec 2007 16:38:01 -0800
> > Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > > Here's some other ideas for how to express EAPI. What if we:
> > > 
> > > Used EAPI-named subdirectories instead of tagging it into the
> > > filename?
> > 
> > Performance hit, and otherwise equivalent to using suffixes.
> 
> Not quite so ugly-looking to my eyes.

It makes it quite a bit harder for developers to find the ebuild...

> > > Used (and required) filesystem extended attributes?
> > 
> > Unportable, unsyncable and unmaintainable.
> 
> Unportable to filesystems that don't support extended attributes
> isn't very interesting to me, unless they're common. Out of
> curiosity, do you know which ones that would be? Looking at my kernel
> config, ext3 and reiser explicitly support xattrs, and I see jfs and
> xfs have acls and security labels, which might be usable. Unsyncable
> would be a problem, so it's a good thing rsync has USE=xattr

That's an awful lot of requirements you're imposing upon people...

> do the difficulties come in on the CVS side?

Version control systems don't tend to do anything beyond very basic
permission related things... Getting the executable bit right is about
the best you can hope for.

> Why do you say unmaintainable?

Because they're almost entirely invisible.

> > > Stuck ranges into metadata.xml for which EAPIs applied?
> > 
> > No package manager required information can be in XML format.
> 
> Says who? Us. We can change that, if we decide it's the best answer.
> =)

Say the Portage people for the past lots of years.

(The reason, primarily, used to be that it used to be a dep upon a .so
that could get broken. A better reason is that parsing XML is frickin'
slow.)

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Marius Mauch]

On Thu, 20 Dec 2007 09:55:06 +0000
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> > > > Stuck ranges into metadata.xml for which EAPIs applied?
> > > 
> > > No package manager required information can be in XML format.
> > 
> > Says who? Us. We can change that, if we decide it's the best answer.
> > =)
> 
> Say the Portage people for the past lots of years.

I assume you're referring to some statements I and maybe Nick made several years ago, I don't think Brian, Jason or Zac ever really thought about it. I can only speak for myself, but those past statements were mostly due to experiences made with glsa-check and issues in the python/pyxml relationship (in 2003), things may have changed since then so those statements could be re-evaluated.

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Luca Barbato]

Donnie Berkholz wrote:
> Here's some other ideas for how to express EAPI. What if we:

If this idea of eapi is the best. I'm doubtful it is.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP] Use EAPI inside ebuild filename (.EAPI-ebuild of different?)

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

While it's may be a good idea to set EAPI inside filename and if we ever
decide on this, consider different implementation.

I really dislike idea of EAPI-suffixed extensions. It's easier for me
(and I think for others too) to differentiate ebuilds between other
files in directory when ebuild files have common suffix. We are people
so we should simplify things that are not hidden under the hood, like
this...

This hack is just to solve portage problem which does not ignore .ebuild
files which does not follow pkg-ver.ebuild syntax and suggested solution
is not the only solution. Other possibilities are, which I like more:

1. USE pkg-ver.<EAPI>-ebuild

2. USE pkg-ver${EAPITAG}<EAPI>.ebuild
   Here ${EAPITAG} is string to simplify parsing <EAPI> from
   version. E.g. EAPITAG could be _eapi or EAPI or something
   else.

Although second solution does not solve the problem with portage I like
it more, as we all have habit to look at .ebuild suffix. But this is
different problem. Once we define good NEW format for filename it's
possible to decide on transition path which allows us to use eapi right
now. E.g. start using this format only with .ebuild-ng suffix and after
three years pass it's possible to rename all .ebuild-ng into .ebuild.


And another idea which was already mentioned somewhere in this thread. I
think .ebuild should be written only in BASH. Again if we ever decide to
use ebuilds with different syntax we should use different suffix.

-- 
Peter.

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP] Use EAPI inside ebuild filename (.EAPI-ebuild of different?)

[Marius Mauch]

On Thu, 20 Dec 2007 15:50:02 +0300
Peter Volkov <pva@gentoo.org> wrote:

> This hack is just to solve portage problem which does not ignore .ebuild
> files which does not follow pkg-ver.ebuild syntax and suggested solution
> is not the only solution. Other possibilities are, which I like more:
> 
> 1. USE pkg-ver.<EAPI>-ebuild

Same thing really, just looks even messier IMO.

> 2. USE pkg-ver${EAPITAG}<EAPI>.ebuild
>    Here ${EAPITAG} is string to simplify parsing <EAPI> from
>    version. E.g. EAPITAG could be _eapi or EAPI or something
>    else.

Isn't backwards compatible in any way.

Marius
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

Piotr Jaroszyński kirjoitti:
> This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for
> example, foo-1.2.3.ebuild-1).

It seems many people don't like the idea of having it in the filename
but how about having subdirectories for different eapis. This should
even be faster for the package manager as it can just ignore the
directories it can't understand instead of having to parse the file names.

example:

${PORTDIR}/<category>/<pkg>/eapiX/

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes

[Piotr Jaroszyński]

On Saturday 22 of December 2007 02:41:02 Petteri Räty wrote:
> Piotr Jaroszyński kirjoitti:
> > This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds
> > (for example, foo-1.2.3.ebuild-1).
>
> It seems many people don't like the idea of having it in the filename

Seems you are counting the posts, not the people.

> but how about having subdirectories for different eapis. This should
> even be faster for the package manager as it can just ignore the
> directories it can't understand instead of having to parse the file names.

It was already proposed, but didn't seem to get much support. It is equivalent 
to using the suffixes, but I see it rather as perfomarnce hit, not 
improvement. The package manger would have to look for ebuilds in the main 
dir and all the subdirs in case it doesn't have/can't use the cache.

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [GLEP 55] EAPI subdirectories instead of file name suffixes

[Steve Long]

Piotr Jaroszy?ski wrote:

> On Saturday 22 of December 2007 02:41:02 Petteri Räty wrote:
>> Piotr Jaroszy?ski kirjoitti:
>> > This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds
>> > (for example, foo-1.2.3.ebuild-1).
>>
>> It seems many people don't like the idea of having it in the filename
> 
> Seems you are counting the posts, not the people.
> 
>> but how about having subdirectories for different eapis. This should
>> even be faster for the package manager as it can just ignore the
>> directories it can't understand instead of having to parse the file
>> names.
> 
> It was already proposed, but didn't seem to get much support.
That would be counting posts, not people. It just hasn't been discussed.

> It is 
> equivalent to using the suffixes, but I see it rather as perfomarnce hit,
> not improvement. The package manger would have to look for ebuilds in the
> main dir and all the subdirs in case it doesn't have/can't use the cache.
> 
Yeah but this isn't about performance (or so I heard. I took that to mean it
was about ebuilds which can't be sourced, but you might want to check
exactly what McCreesh meant, since I am apparently incapable of
understanding his missives.)

Given that, the subdirectories would do the job fine, and end-users don't
have to worry about building the cache anyway.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

Piotr Jaroszyński wrote:
> The package manger would have to look for ebuilds in the main 
> dir and all the subdirs in case it doesn't have/can't use the cache.

No, it would have to check only for subdirectories named after known and
supported EAPIs.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes

[Piotr Jaroszyński]

On Saturday 22 of December 2007 10:50:40 Jan Kundrát wrote:
> Piotr Jaroszyński wrote:
> > The package manger would have to look for ebuilds in the main
> > dir and all the subdirs in case it doesn't have/can't use the cache.
>
> No, it would have to check only for subdirectories named after known and
> supported EAPIs.

Not really, we still want to show ebuilds with unsupported EAPI  as being 
masked, but I agree it will have to check only eapiX subdirs. It's still a 
performance hit though.

-- 
Best Regards,
Piotr Jaroszyński
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

On Sat, 22 Dec 2007 03:41:02 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:
> Piotr Jaroszyński kirjoitti:
> > This GLEP proposes usage of EAPI-suffixed file extensions for
> > ebuilds (for example, foo-1.2.3.ebuild-1).
> 
> It seems many people don't like the idea of having it in the filename
> but how about having subdirectories for different eapis. This should
> even be faster for the package manager as it can just ignore the
> directories it can't understand instead of having to parse the file
> names.
> 
> example:
> 
> ${PORTDIR}/<category>/<pkg>/eapiX/

In terms of what it does and doesn't allow, this one's equivalent. But
it has some new disadvantages:

* It's several more directory reads. This is a measurable performance
hit on something that's already i/o bound.

* It's harder to work with for developers. Ebuilds are no longer all in
the same place, and it's harder to see what you're working with.

On a subjective niceness scale, I'd suspect that the file extension is
less unnice.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]

On Sat, Dec 22, 2007 at 07:09:30AM +0000, Ciaran McCreesh wrote:
> On Sat, 22 Dec 2007 03:41:02 +0200
> Petteri Räty <betelgeuse@gentoo.org> wrote:
> > Piotr Jaroszyński kirjoitti:
> > > This GLEP proposes usage of EAPI-suffixed file extensions for
> > > ebuilds (for example, foo-1.2.3.ebuild-1).
> > 
> > It seems many people don't like the idea of having it in the filename
> > but how about having subdirectories for different eapis. This should
> > even be faster for the package manager as it can just ignore the
> > directories it can't understand instead of having to parse the file
> > names.
> > 
> > example:
> > 
> > ${PORTDIR}/<category>/<pkg>/eapiX/
> 
> In terms of what it does and doesn't allow, this one's equivalent. But
> it has some new disadvantages:
> 
> * It's several more directory reads. This is a measurable performance
> hit on something that's already i/o bound.

Among other things, because readdirs cannot be neither readahead nor
'advised'. Which is STUPIDLY slow. So adding yet another directory to
the hierarchy is quite silly.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]