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

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

[Piotr Jaroszyński]

[-- Attachment #1.1: Type: text/plain, Size: 352 bytes --]

Hello,

I have updated the GLEP, hopefully it is less confusing now and hence the discussion will be more technical.

As I still didn't get the "ok to commit" from our glep folks, read the most current version here:
http://dev.gentoo.org/~peper/glep-0055.html
http://dev.gentoo.org/~peper/glep-0055.txt

-- 
Best Regards,
Piotr Jaroszyński

[-- Attachment #1.2: Type: text/html, Size: 570 bytes --]

[-- Attachment #2: glep-0055.txt --]
[-- Type: text/plain, Size: 6603 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, 22-Dec-2007

  "A little learning is a dangerous thing; drink deep, or taste not the Pierian
  spring: there shallow draughts intoxicate the brain, and drinking largely
  sobers us again."

  -- Alexander Pope, An Essay on Criticism

Abstract
========

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

Problem
=======

The current way of specifying the EAPI in ebuilds is flawed. In order to get the
EAPI the package manager needs to source the ebuild, which itself needs the EAPI
in the first place. Otherwise it imposes a serious limitation, namely every ebuild,
using any of the future EAPIs, will have to be source'able by old package
managers and hence there is no way to:

  *  Change behaviour of inherit in any way (for example, to extend or change
     eclass functionality).

  *  Add new global scope functions in any sane way.

  *  Extend versioning rules in an EAPI - for example, addition of the scm
     suffix - GLEP54 [#GLEP54]_.


Abstract solution
=================

A solution to this problem has to lift those limitations and the only way to do
it is to make the EAPI of an ebuild available to the package managers in a way
that doesn't require them to source the ebuild. Another important requirement is
for the solution to be backward compatible, which has the pleasant side-effect
of making the solution applicable in the Gentoo tree right away. Opposed to
waiting an arbitrary amount of time, which is never long enough anyway, as the
issues listed on the common portage problems page - [#PortageProblems]_ - show.

Proposed solution
=================

The proposed solution is to use EAPI-suffixed file extensions for ebuilds. This
allows package managers to trivially read the EAPI from the ebuild filename. It
is also backward compatible, because currently ebuilds are recognised by the
``.ebuild`` file extension and hence EAPI-suffixed ebuilds are simply ignored by
the package managers.


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-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-3.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 (assuming the
       package manager didn't die when sourcing the ebuild thinking that EAPI 0
       is used).
       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.

Application
===========

Note that the developers should only set the pre-source EAPI. The process
described above is only necessary to avoid undefined behaviour in corner cases
and to retain backwards compatibility.

QA tools may warn if the post-source EAPI is set at all, thus helping with the
transition to the new format.

Other ideas
===========

There were some other solutions proposed on the mailing list:

  *  Set the EAPI inside the ebuild in a way that makes it easy to fetch it
       *  Doesn't meet the backward compatibility requirement.
       *  Isn't forward compatible either.
       *  Could be confusing as ebuilds, and not without a reason, are
          considered bash scripts and this would impose additional restrictions.

  *  Do the above and change the ebuild extension to ``.ebuild-ng``
       *  Meets the backward compatibility requirement.
       *  Still can be confusing.
       *  Isn't really forward compatible. What would be after ``.ebuild-ng``?
          ``.ebuild-ng-ng``?

  *  Use different subdirectories for different EAPIs, i.e. cat/pkg/eapiX/
       *  Meets both requirements.
       *  Introduces a noticeable performance hit (several more directory reads
          in an I/O bound operation).
       *  Makes it much harder for maintainers to see what they have.


References
==========

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

.. [#PortageProblems] Common portage problems
    (http://www.gentoo.org/proj/en/portage/doc/common-problems.xml)

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) [2]

[Daniel Drake]

Piotr Jaroszyński wrote:
> I have updated the GLEP, hopefully it is less confusing now and hence 
> the discussion will be more technical.
> 
> As I still didn't get the "ok to commit" from our glep folks, read the 
> most current version here:
> 
> http://dev.gentoo.org/~peper/glep-0055.html
> 
> http://dev.gentoo.org/~peper/glep-0055.txt

Haven't read the previous discussion, apologies if this has been 
clarified already, but I think it would be good to answer the following 
question in the GLEP:

Why (in terms of your GLEP) are you still allowing ebuilds to set EAPI 
inside the ebuild?

It seems that one approach you might take is to move the EAPI selection 
into the filename and remove it from the ebuild itself, and it's not 
clear to me why your proposal isn't exactly that.

Thanks,
Daniel

-- 
gentoo-dev@gentoo.org mailing list

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

[Piotr Jaroszyński]

On Saturday 22 of December 2007 18:56:12 Daniel Drake wrote:
> Why (in terms of your GLEP) are you still allowing ebuilds to set EAPI
> inside the ebuild?
>
> It seems that one approach you might take is to move the EAPI selection
> into the filename and remove it from the ebuild itself, and it's not
> clear to me why your proposal isn't exactly that.

That's the goal, yes. The "Specification" part shows how to do that in a 
backward compatible way and the "Application" part says how is the new format 
supposed to be used. But seeing it's not clear enough I will look into it.

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

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

[Duncan]

Piotr Jaroszyński <peper@gentoo.org> posted
200712221643.11516.peper@gentoo.org, excerpted below, on  Sat, 22 Dec 2007
16:43:10 +0100:

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

This one does seem a marked improvement.  Thanks.  It really is 
noticeably better. =8^)


> Specification
> =============

I made this suggestion earlier but it was deep in a subthread and perhaps 
missed.  Else, maybe it didn't reach you in time for this update.  
Anyway, here it is again:

Right at this point, between the Specification header and the existing 
"Let's call"... below, for clarity I believe we need a formal syntax 
note, probably similar in format to the the one found in many manpages, 
where it is called "Synopsis".  Checking other GLEPs, I don't see 
anything like this in most, but I do believe it /would/ help clarify and 
is thus worth it.  Like the following (I'm omitting the RST stuff):

Syntax:

<PF>.ebuild[-<EAPI>]

Where:

<PF> is the full package name, version, and revision, as in man 5 ebuild.

-<EAPI> is optional.

<EAPI> is the named EAPI.

Explanation:

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

It may also be worthwhile to specifically note /somewhere/ that this only 
specifies *.ebuild* format, thus leaving other forms (say xbuild) for 
further changes, if it should ever be decided necessary.

Combined, these two changes would have significantly reduced my initial 
confusion upon reading the GLEP, thus leading to a false impression and 
raising objections to the idea that didn't apply, once I understood more 
clearly what, specifically, was being proposed.

-- 
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) [2]

[Duncan]

Daniel Drake <dsd@gentoo.org> posted 476D4FBC.1040203@gentoo.org,
excerpted below, on  Sat, 22 Dec 2007 17:56:12 +0000:

>> http://dev.gentoo.org/~peper/glep-0055.html
>> 
>> http://dev.gentoo.org/~peper/glep-0055.txt
> 
> Haven't read the previous discussion, apologies if this has been
> clarified already, but I think it would be good to answer the following
> question in the GLEP:
> 
> Why (in terms of your GLEP) are you still allowing ebuilds to set EAPI
> inside the ebuild?
> 
> It seems that one approach you might take is to move the EAPI selection
> into the filename and remove it from the ebuild itself, and it's not
> clear to me why your proposal isn't exactly that.

Actually, that was clarified in this new version.  Is the following (from 
the Application section) sufficient?  Maybe pre-source EAPI and post-
source EAPI aren't clearly enough defined?  (Their def is in the first 
paragraph under specification.)

<quote>

Note that the developers should only set the pre-source EAPI. The process
described above is only necessary to avoid undefined behaviour in corner
cases and to retain backwards compatibility.

QA tools may warn if the post-source EAPI is set at all, thus helping with
the transition to the new format.

</quote>

As I had read the first version, that leapt out at me.  Did you just miss 
it or do you still believe it needs clarified further?

-- 
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) [2]

[Piotr Jaroszyński]

On Saturday 22 of December 2007 19:26:08 Duncan wrote:
> I made this suggestion earlier but it was deep in a subthread and perhaps
> missed.  Else, maybe it didn't reach you in time for this update.
> Anyway, here it is again:
(snip)
> Syntax:
> 
> <PF>.ebuild[-<EAPI>]

Thanks, added syntax specification for the ebuild filename extension.

> It may also be worthwhile to specifically note /somewhere/ that this only
> specifies *.ebuild* format, thus leaving other forms (say xbuild) for
> further changes, if it should ever be decided necessary.

I think it will be the job of the xbuild GLEP to specify what from the ebuild 
format applies and what does not.

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

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

[Steve Long]

Piotr Jaroszy?ski wrote:

> Hello,
> 
> I have updated the GLEP, hopefully it is less confusing now and hence the
> discussion will be more technical.
> 
Based on your summary of the suggestions on the list, I believe you
misunderstood what many of us were arguing for.

*  Set the EAPI inside the ebuild in a way that makes it easy to fetch it
  This is ok as atm only EAPI=1 is in the tree, so there is no backward
compatibility issue.
AND
*  Have a new ebuild/eclass extension ".eapi-$EAPI"
  This is for ebuilds for other package managers; it is envisaged by some
that this will become the new ebuild format since it enables quick access
to the EAPI without accessing the file contents. Full ebuild names are the
primary key for the portage database.


-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Mon, 24 Dec 2007 06:03:12 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> *  Set the EAPI inside the ebuild in a way that makes it easy to
> fetch it This is ok as atm only EAPI=1 is in the tree, so there is no
> backward compatibility issue.

It's both a backwards and a forwards compatibility issue.

> *  Have a new ebuild/eclass extension ".eapi-$EAPI"
>   This is for ebuilds for other package managers; it is envisaged by
> some that this will become the new ebuild format since it enables
> quick access to the EAPI without accessing the file contents. Full
> ebuild names are the primary key for the portage database.

Full ebuild names as a primary key is bad. It means you have to
normalise versions early on -- equality and equivalence are different
for ebuild names already.

And eclasses are an entirely separate issue. They need to be dealt with
differently, ideally starting with EAPI 2.

-- 
Ciaran McCreesh

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

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

[Steve Long]

Ciaran McCreesh wrote:
> On Mon, 24 Dec 2007 06:03:12 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> *  Set the EAPI inside the ebuild in a way that makes it easy to
>> fetch it This is ok as atm only EAPI=1 is in the tree, so there is no
>> backward compatibility issue.
> 
> It's both a backwards and a forwards compatibility issue.
>
Yeah, so forwards into the future where it's impossible to maintain this
format (er..) there'll be another type of ebuild for your purported
long-term solution.
 
>> *  Have a new ebuild/eclass extension ".eapi-$EAPI"
>>   This is for ebuilds for other package managers; it is envisaged by
>> some that this will become the new ebuild format since it enables
>> quick access to the EAPI without accessing the file contents.
<snip trivia about backend database formats>

> And eclasses are an entirely separate issue. They need to be dealt with
> differently, ideally starting with EAPI 2.
> 
But they come under the scope of this discussion, since this is about the
long-term future of *every* EAPI. So let's discuss them.


-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

On Mon, 24 Dec 2007 10:52:53 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Ciaran McCreesh wrote:
> > On Mon, 24 Dec 2007 06:03:12 +0000
> > Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> >> *  Set the EAPI inside the ebuild in a way that makes it easy to
> >> fetch it This is ok as atm only EAPI=1 is in the tree, so there is
> >> no backward compatibility issue.
> > 
> > It's both a backwards and a forwards compatibility issue.
> >
> Yeah, so forwards into the future where it's impossible to maintain
> this format (er..) there'll be another type of ebuild for your
> purported long-term solution.

Hopefully that'll be EAPI 2, and hopefully we're talking months rather
than years.

> > And eclasses are an entirely separate issue. They need to
> > be dealt with differently, ideally starting with EAPI 2.
> > 
> But they come under the scope of this discussion, since this is about
> the long-term future of *every* EAPI. So let's discuss them.

Ok. What technically sound ideas that have been implemented in a real
package manager and tried out on a large, real tree maintained by
multiple developers do you have about improving eclasses with respect
to EAPI handling? I'm curious, because the only solutions we have for
working with the current system are going to suck in the long term (but
equally, they do work with EAPI 0/1, which means they're fine for short
term), and I've yet to hear of a solution that is implementable (both
theoretically and practically), usable from a tree perspective and
scalable across EAPIs.

To start you off, here's a list of ideas that suck:

* Per-EAPI eclasses, or a master eclass that uses sub-eclasses for
whichever EAPI is in use. This is the best general current solution, but
it gets messy very quickly with new EAPIs.

* Eclasses enforcing EAPI restrictions either by global scope or
pkg_setup die. The former's illegal, breaks the metadata cache as it's
done currently, and is way too easy for developers to screw up. The
latter is way too easy for developers to screw up, results in users
seeing the mess and doesn't allow package managers to work around it.

* Variant: eclasses forcibly setting EAPI to OOPS-SOMEONE-SCREWED-UP if
they don't support the eclass used. This one's actually ok from a
package manager perspective, but lousy from a developer testing thing
perspective.

* Eclasses modifying EAPI. Doesn't scale across multiple eclasses, nor
across EAPIs removing features, nor EAPIs changing eclasses.

* Some kind of list of supported EAPIs in an eclass. Still has to deal
with EAPI 0 and 1, and doesn't work well across multiple eclasses.

* Banning eclasses from using anything that isn't supported in every
EAPI. Makes new features rather useless, and removing things rather
difficult...

* Crazy hackery involving making 'inherit' look somewhere else in
future EAPIs. At best you'd end up having stub eclasses (again with no
particularly nice way of saying 'oops') to deal with EAPIs 0 and 1.

* Introduce some new global scope eclass-like function that, combined
with supported EAPI sets, does have a proper way of signalling 'not
supported' (and throw in per cat/pkg eclasses because you can).
Unfortunately, you can't do this without breaking current EAPI 0 / 1
package managers, unless you also switch file extensions or some
equivalent op.

All but the last of these are nowhere near good enough. The last one
may or may not be OK as a starting point, but everyone I've spoken to
who's worked with a real multiple EAPI repo agrees that it's a long way
off being a good enough idea that it's worth considering having serious
discussion about it.

So go ahead and start discussing eclasses, if you want. But first I
suggest getting lots and lots of experience and making damned sure you
understand how everything works...

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

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

[Roy Marples]

Just picked this particular email to reply with my thoughts on this
thread.

On Mon, 2007-12-24 at 10:52 +0000, Steve Long wrote:
> But they come under the scope of this discussion, since this is about the
> long-term future of *every* EAPI. So let's discuss them

Impossible. History has proven again and again that you cannot predict
every aspect of the future. But then I'm sure you know this ;)

File name suffixes historically describe the content structure of a
file.

.png means the content is a picture and it's structure is Portable
Network Graphic.

.ebuild means the content is instructions on how to install something
and it's structure is bash.

So to obtain EAPI from .ebuild you would always do
EAPI=`. /path/to/ebuild.ebuild; echo "${EAPI}"`

Now say you wanted to move ebuilds into xml you would do
EAPI=`xmlcmd_to_extract_node_value /root/eapi /path/to/ebuild.xml"

In closing, EAPI describes features available, not content nor
structure.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

On Dec 24, 2007 7:53 AM, Roy Marples <roy@marples.name> wrote:
> So to obtain EAPI from .ebuild you would always do
> EAPI=`. /path/to/ebuild.ebuild; echo "${EAPI}"`

Doesn't work with current ebuilds, nor future ebuilds. No points!

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

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

[Roy Marples]

On Tue, 2007-12-25 at 02:26 -0500, Ciaran McCreesh wrote:
> On Dec 24, 2007 7:53 AM, Roy Marples <roy@marples.name> wrote:
> > So to obtain EAPI from .ebuild you would always do
> > EAPI=`. /path/to/ebuild.ebuild; echo "${EAPI}"`
> 
> Doesn't work with current ebuilds, nor future ebuilds. No points!

Works fine as long as the functions the ebuild has in global scope
exist. Which would assuming that the ebuild was sourced in a portage
environment.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

On Dec 25, 2007 2:38 AM, Roy Marples <roy@marples.name> wrote:
> On Tue, 2007-12-25 at 02:26 -0500, Ciaran McCreesh wrote:
> > On Dec 24, 2007 7:53 AM, Roy Marples <roy@marples.name> wrote:
> > > So to obtain EAPI from .ebuild you would always do
> > > EAPI=`. /path/to/ebuild.ebuild; echo "${EAPI}"`
> >
> > Doesn't work with current ebuilds, nor future ebuilds. No points!
>
> Works fine as long as the functions the ebuild has in global scope
> exist. Which would assuming that the ebuild was sourced in a portage
> environment.

Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI
1 environment, or what? What happens when EAPI 2 changes the behaviour
of inherit? What happens when EAPI 2 introduces a new global scope
function that sources a new kind of eclass that current package
managers don't support?

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

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

[Roy Marples]

On Tue, 2007-12-25 at 02:43 -0500, Ciaran McCreesh wrote:
> On Dec 25, 2007 2:38 AM, Roy Marples <roy@marples.name> wrote:
> > On Tue, 2007-12-25 at 02:26 -0500, Ciaran McCreesh wrote:
> > > On Dec 24, 2007 7:53 AM, Roy Marples <roy@marples.name> wrote:
> > > > So to obtain EAPI from .ebuild you would always do
> > > > EAPI=`. /path/to/ebuild.ebuild; echo "${EAPI}"`
> > >
> > > Doesn't work with current ebuilds, nor future ebuilds. No points!
> >
> > Works fine as long as the functions the ebuild has in global scope
> > exist. Which would assuming that the ebuild was sourced in a portage
> > environment.
> 
> Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI
> 1 environment, or what?

If it's that such a big deal, then simply ensure that

1) no functions are allowed in global scope
or
2) eapi is a function and not a variable

Thanks

Roy

PS - Merry Christmas everyone - I'm off to enjoy mine with my family
now. I suggest everyone else does the same :)

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

On 12/25/07, Roy Marples <roy@marples.name> wrote:
> > Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI
> > 1 environment, or what?
>
> If it's that such a big deal, then simply ensure that

Thankyou for reading and understanding the GLEP before jumping in and
commenting.

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

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

[Roy Marples]

On Tue, 2007-12-25 at 04:16 -0500, Ciaran McCreesh wrote:
> On 12/25/07, Roy Marples <roy@marples.name> wrote:
> > > Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI
> > > 1 environment, or what?
> >
> > If it's that such a big deal, then simply ensure that
> 
> Thankyou for reading and understanding the GLEP before jumping in and
> commenting.

I understand that metadata in a file name is pure and simple hackery
that has no place here and the GLEP is a flimsy attempt to justify it.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

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

[Doug Klima]

Roy Marples wrote:
> On Tue, 2007-12-25 at 04:16 -0500, Ciaran McCreesh wrote:
>   
>> On 12/25/07, Roy Marples <roy@marples.name> wrote:
>>     
>>>> Ok. So do you use an EAPI 0 environment to do the sourcing, or an EAPI
>>>> 1 environment, or what?
>>>>         
>>> If it's that such a big deal, then simply ensure that
>>>       
>> Thankyou for reading and understanding the GLEP before jumping in and
>> commenting.
>>     
>
> I understand that metadata in a file name is pure and simple hackery
> that has no place here and the GLEP is a flimsy attempt to justify it.
>
> Thanks
>
> Roy
>
>   
Roy++
-- 
gentoo-dev@gentoo.org mailing list

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

[Jan Kundrát]

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

Roy Marples wrote:
> I understand that metadata in a file name is pure and simple hackery
> that has no place here and the GLEP is a flimsy attempt to justify it.

Do you count "version" as metadata?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


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

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

[Roy Marples]

On Thu, 2007-12-27 at 16:39 +0100, Jan Kundrát wrote:
> Roy Marples wrote:
> > I understand that metadata in a file name is pure and simple hackery
> > that has no place here and the GLEP is a flimsy attempt to justify it.
> 
> Do you count "version" as metadata?

No.

-- 
gentoo-dev@gentoo.org mailing list

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

[Rémi Cardona]

Jan Kundrát a écrit :
> Roy Marples wrote:
>> I understand that metadata in a file name is pure and simple hackery
>> that has no place here and the GLEP is a flimsy attempt to justify it.
> 
> Do you count "version" as metadata?

I'll bite :)

Version numbers aren't metadata because they uniquely identify the
ebuild/package.

EAPI on the other hand brings no such information to identify the
package. Furthermore, the GLEP proposes that no 2 ebuilds with the exact
same version may exist regardless of different EAPIs.

In the end, ${CATEGORY}/${PF} is like the key in a RDB table. The EAPI
is just extra info.

I'll just wrap this up by saying that I don't have an opinion on whether
putting the EAPI inside the ebuild or outside is better for the complex
operations involved in portage. I'll leave that to the more informed devs :)

Cheers,

Rémi
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Thu, 27 Dec 2007 15:04:52 +0000
Roy Marples <roy@marples.name> wrote:
> I understand that metadata in a file name is pure and simple hackery
> that has no place here and the GLEP is a flimsy attempt to justify it.

Alright, so where would you stick EAPI such that all the requirements
that've previously been described are met?

-- 
Ciaran McCreesh

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

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

[Roy Marples]

On Thu, 2007-12-27 at 16:32 +0000, Ciaran McCreesh wrote:
> On Thu, 27 Dec 2007 15:04:52 +0000
> Roy Marples <roy@marples.name> wrote:
> > I understand that metadata in a file name is pure and simple hackery
> > that has no place here and the GLEP is a flimsy attempt to justify it.
> 
> Alright, so where would you stick EAPI such that all the requirements
> that've previously been described are met?

I neither know, nor care.

I just feel very strongly that the current proposal is wrong, and no
requirements that you or others may have can possibly outweigh that.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Thu, 27 Dec 2007 16:45:06 +0000
Roy Marples <roy@marples.name> wrote:
> > Alright, so where would you stick EAPI such that all the
> > requirements that've previously been described are met?
> 
> I neither know, nor care.
> 
> I just feel very strongly that the current proposal is wrong, and no
> requirements that you or others may have can possibly outweigh that.

So you have no technical objections, no alternatives, no understanding
of why it's necessary and no actual reason to call it 'wrong'.

-- 
Ciaran McCreesh

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

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

[Roy Marples]

On Thu, 2007-12-27 at 16:50 +0000, Ciaran McCreesh wrote:
> On Thu, 27 Dec 2007 16:45:06 +0000
> Roy Marples <roy@marples.name> wrote:
> > > Alright, so where would you stick EAPI such that all the
> > > requirements that've previously been described are met?
> > 
> > I neither know, nor care.
> > 
> > I just feel very strongly that the current proposal is wrong, and no
> > requirements that you or others may have can possibly outweigh that.
> 
> So you have no technical objections, no alternatives, no understanding
> of why it's necessary and no actual reason to call it 'wrong'.

Hard to have technical objections to the contents of a string :)

Actual reasons were stated in the first email I posted in this thread to
which to replied.

I care not for alternatives, nor understanding as it's not my domain of
expertise or knowledge.

But I can smell a blatant hack that is just wrong to the bone like a lot
of other people here.

Just because you have a the only "solution" to a problem does not make
it "right" by default.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Thu, 27 Dec 2007 17:27:05 +0000
Roy Marples <roy@marples.name> wrote:
> But I can smell a blatant hack that is just wrong to the bone like a
> lot of other people here.

Clearly not... As you say, you don't care to understand any of this.
You're just jumping in because you think you know what a file extension
is and are thus qualified to comment. Unfortunately, the file extension
is largely irrelevant -- it's merely the end result, and it's
everything that leads up to that that's the important part.

Or to put it another way, you're objecting to painting the house pink
rather than green because you don't like pink (because your last house
was green too), ignoring that it's been demonstrated that when painted
green, it's impossible to add a conservatory and central heating
because the green paint will catch fire and kill everyone.

-- 
Ciaran McCreesh

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

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

[Roy Marples]

On Thu, 2007-12-27 at 17:43 +0000, Ciaran McCreesh wrote:
> Or to put it another way, you're objecting to painting the house pink
> rather than green because you don't like pink (because your last house
> was green too), ignoring that it's been demonstrated that when painted
> green, it's impossible to add a conservatory and central heating
> because the green paint will catch fire and kill everyone.

Using your analogy you should then recognise that there is a strong
dislike for pink and should seek a new colour that allows the building
of said extensions.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Thu, 27 Dec 2007 18:03:27 +0000
Roy Marples <roy@marples.name> wrote:
> On Thu, 2007-12-27 at 17:43 +0000, Ciaran McCreesh wrote:
> > Or to put it another way, you're objecting to painting the house
> > pink rather than green because you don't like pink (because your
> > last house was green too), ignoring that it's been demonstrated
> > that when painted green, it's impossible to add a conservatory and
> > central heating because the green paint will catch fire and kill
> > everyone.
> 
> Using your analogy you should then recognise that there is a strong
> dislike for pink and should seek a new colour that allows the building
> of said extensions.

And what colour would that be? We've already ruled out purple, brown
and yellow, and no-one has yet found any other colour of paint.

-- 
Ciaran McCreesh

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

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

[Chris Gianelloni]

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

On Thu, 2007-12-27 at 18:11 +0000, Ciaran McCreesh wrote:
> On Thu, 27 Dec 2007 18:03:27 +0000
> Roy Marples <roy@marples.name> wrote:
> > On Thu, 2007-12-27 at 17:43 +0000, Ciaran McCreesh wrote:
> > > Or to put it another way, you're objecting to painting the house
> > > pink rather than green because you don't like pink (because your
> > > last house was green too), ignoring that it's been demonstrated
> > > that when painted green, it's impossible to add a conservatory and
> > > central heating because the green paint will catch fire and kill
> > > everyone.
> > 
> > Using your analogy you should then recognise that there is a strong
> > dislike for pink and should seek a new colour that allows the building
> > of said extensions.
> 
> And what colour would that be? We've already ruled out purple, brown
> and yellow, and no-one has yet found any other colour of paint.

Any chance we can back on, you know, the actual topic, rather than these
useless analogies?

Thanks,

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Foundation Trustee
Gentoo Foundation

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

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

[Roy Marples]

On Thu, 2007-12-27 at 18:11 +0000, Ciaran McCreesh wrote:
> On Thu, 27 Dec 2007 18:03:27 +0000
> Roy Marples <roy@marples.name> wrote:
> > On Thu, 2007-12-27 at 17:43 +0000, Ciaran McCreesh wrote:
> > > Or to put it another way, you're objecting to painting the house
> > > pink rather than green because you don't like pink (because your
> > > last house was green too), ignoring that it's been demonstrated
> > > that when painted green, it's impossible to add a conservatory and
> > > central heating because the green paint will catch fire and kill
> > > everyone.
> > 
> > Using your analogy you should then recognise that there is a strong
> > dislike for pink and should seek a new colour that allows the building
> > of said extensions.
> 
> And what colour would that be? We've already ruled out purple, brown
> and yellow, and no-one has yet found any other colour of paint.

If there are no other colours then maybe you shouldn't install
extensions that only work with pink to the detriment of all other
colours of the spectrum.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

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

[Steve Long]

Ciaran McCreesh wrote:
> On Mon, 24 Dec 2007 10:52:53 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> Ciaran McCreesh wrote:
>> > On Mon, 24 Dec 2007 06:03:12 +0000
>> > Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> >> *  Set the EAPI inside the ebuild in a way that makes it easy to
>> >> fetch it This is ok as atm only EAPI=1 is in the tree, so there is
>> >> no backward compatibility issue.
>> > 
>> > It's both a backwards and a forwards compatibility issue.
>> >
>> Yeah, so forwards into the future where it's impossible to maintain
>> this format (er..) there'll be another type of ebuild for your
>> purported long-term solution.
> 
> Hopefully that'll be EAPI 2, and hopefully we're talking months rather
> than years.
>
Whatever. EAPI="2" works fine with current software. Could you tell me why
you're so hot on export'ing EAPI? I thought it was only relevant,
environment-wise, to the ebuild and subshells. What is the use case for
exporting it externally?

> * Eclasses modifying EAPI. Doesn't scale across multiple eclasses, nor
> across EAPIs removing features, nor EAPIs changing eclasses.
> 
I don't see what's wrong with EAPI (if set, otherwise implicitly whatever
the ebuild sets, or 0 if not set there) only applying to the file it's
declared in.

Since we can't remove eclasses, it would be useful to continue allowing them
to examine the EAPI variable for future compatibility. I'm sure there are
other restrictions imposed by this "enhancement" which make maintenance
more difficult for no benefit to the maintainer.


-- 
gentoo-dev@gentoo.org mailing list

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

[Marius Mauch]

On Fri, 28 Dec 2007 05:21:06 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:

> I don't see what's wrong with EAPI (if set, otherwise implicitly whatever
> the ebuild sets, or 0 if not set there) only applying to the file it's
> declared in.

Because that doesn't work at all, see 
http://article.gmane.org/gmane.linux.gentoo.devel/53354

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

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

[Ciaran McCreesh]

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

On Fri, 28 Dec 2007 05:21:06 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Whatever. EAPI="2" works fine with current software. Could you tell
> me why you're so hot on export'ing EAPI? I thought it was only
> relevant, environment-wise, to the ebuild and subshells. What is the
> use case for exporting it externally?

I'm going to ignore you until you post a lengthy explanation of why
what you just said was utter bollocks. You clearly don't have a clue
what you're talking about just now, and by continuing to post nonsense
like the above to the discussion you're wasting everyone's time.

Honestly, that was the single most wrong thing anyone's said in this
entire discussion.

-- 
Ciaran McCreesh

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

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

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> posted
20071227181133.28ff5684@blueyonder.co.uk, excerpted below, on  Thu, 27 Dec
2007 18:11:33 +0000:

> On Thu, 27 Dec 2007 18:03:27 +0000
> Roy Marples <roy@marples.name> wrote:
>> On Thu, 2007-12-27 at 17:43 +0000, Ciaran McCreesh wrote:
>> > Or to put it another way, you're objecting to painting the house pink
>> > rather than green because you don't like pink (because your last
>> > house was green too), ignoring that it's been demonstrated that when
>> > painted green, it's impossible to add a conservatory and central
>> > heating because the green paint will catch fire and kill everyone.
>> 
>> Using your analogy you should then recognise that there is a strong
>> dislike for pink and should seek a new colour that allows the building
>> of said extensions.
> 
> And what colour would that be? We've already ruled out purple, brown and
> yellow, and no-one has yet found any other colour of paint.

OK, I still think putting it in the file name is less prone to error, but 
what about this, call it "blue" if you will?

1) Strictly define and restrict EAPI to a specific form in a specific 
file location (say EAPI=value, unquoted, as the first line of the file).

2) Quickly define say EAPI=1_ext, that further defines say SUB_EAPI, or 
EBPI, or EAPI-B, which is allowed to be a function or whatever, with the 
only further restrictions on it being those that would apply to EAPI-
suffix file names.

That should give us the nailed down qualities of putting it in the file 
name, while providing the flexibility therein as well.  There may be a 
bit of delay while we wait for non-EAPI aware PMs to drop out, but by the 
sounds of things, it's not going to be much more than fighting this thru 
and getting it approved is likely to be (a couple months, anyway), and as 
it's a different EAPI, EAPI aware PMs should ignore it if they don't 
understand it.  PMs can then do a pre-parse, looking at the first line in 
specified format just as they'd otherwise look at the filename.  With 
that information in hand, if the EAPI is 1_ext and they understand that, 
they'll immediately know to check SUB_EAPI or whatever, which is as 
flexible as bash parsing is.  If at some point in the future we want to 
go to XML based formats or whatever, we cross that bridge when we come to 
it and /then/ we do the filename thing, if it's still thought to be 
necessary.  Meanwhile, other (master) EAPIs may yet be defined, if their 
practical use is restricted enough to fit within the strict first line 
EAPI=whatever rule above, and those could include further refinements on 
the SUB_EAPI theme if they become necessary, WITHOUT a multiplication if 
ebuild-xxx extensions.

The big drawback I see here is the the forced delay until EAPI aware PMs 
can be assumed, but as I said, it seems that's going to be the case with 
the current proposal anyway, simply because of the amount of resistance 
to it and the delay in approval that's likely to mean, even if it /is/ 
ultimately approved.

-- 
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: Re: Eclasses (Was: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2])

[Steve Long]

Ciaran McCreesh wrote:

> On Fri, 28 Dec 2007 05:21:06 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> Whatever. EAPI="2" works fine with current software. Could you tell
>> me why you're so hot on export'ing EAPI? I thought it was only
>> relevant, environment-wise, to the ebuild and subshells. What is the
>> use case for exporting it externally?
> 
> I'm going to ignore you until you post a lengthy explanation of why
> what you just said was utter bollocks. You clearly don't have a clue
> what you're talking about just now, and by continuing to post nonsense
> like the above to the discussion you're wasting everyone's time.
> 
> Honestly, that was the single most wrong thing anyone's said in this
> entire discussion.
> 
Er two questions, not statements.
The package manager knows the value; so does bash. Why on earth does, say,
make need to know it?

(Not that it's hard to allow 'export' in the line, just wondering why it
keeps getting raised as required.)


-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Sat, 29 Dec 2007 09:48:33 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> The package manager knows the value; so does bash. Why on earth does,
> say, make need to know it?

Don't think 'make'. Think 'emake'.

-- 
Ciaran McCreesh

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

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

[Federico Ferri]

Ciaran McCreesh ha scritto:
> On Thu, 27 Dec 2007 18:03:27 +0000
> Roy Marples <roy@marples.name> wrote:
>   
>> Using your analogy you should then recognise that there is a strong
>> dislike for pink and should seek a new colour that allows the building
>> of said extensions.
>>     
>
> And what colour would that be? We've already ruled out purple, brown
> and yellow, and no-one has yet found any other colour of paint.
>   
sorry if this has already suggested.
my idea is to use shebang; the advantage in using shebang is that file
doesn't need to be sourced or parsed by complex algorithms in order to
extract the necessary information.

an example:

  #!/usr/bin/ebuild eapi=1
  # Copyright 1999-2007 Gentoo Foundation
  # Distributed under the terms of the GNU General Public License v2
  # $Header: $
 
  DESCRIPTION="My EAPI-1 ebuild"
  HOMEPAGE="http://www.gentoo.org/"
  SRC_URI=""
  LICENSE="GPL-2"
  ...


shebang's synopsis would look something like:

  #!<interpreter> [key=value] [key=value] [...]


pros:
1) it's standard. shell scripts use it. why ebuilds shouldn't?
2) it's easy to parse:
  eval `head -n1 $ebuild | cut -d\  -f2-`; echo $eapi
3) in the future, for any other situation analogous to this, you could
add another key=value to the ebuild's shebang
4) easily checked by repoman

cons:
?

just my two Eurocents.
since now you can bite me ;-)

-- 
#include <stdio.h>
main(){printf("%x",4275974592);}

-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Sun, 30 Dec 2007 00:16:22 +0100
Federico Ferri <xaero@inwind.it> wrote:
> sorry if this has already suggested.

It has. It solves nothing.

-- 
Ciaran McCreesh

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

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

[Roy Marples]

On Sat, 2007-12-29 at 23:20 +0000, Ciaran McCreesh wrote:
> On Sun, 30 Dec 2007 00:16:22 +0100
> Federico Ferri <xaero@inwind.it> wrote:
> > sorry if this has already suggested.
> 
> It has. It solves nothing.
> 

If it solves nothing you should at least post a link to the post you
made explaining so, instead of the user posting "Why?" and another silly
debate starting.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

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

[Marius Mauch]

On Sat, 22 Dec 2007 16:43:10 +0100
Piotr Jaroszyński <peper@gentoo.org> wrote:

> Hello,
> 
> I have updated the GLEP, hopefully it is less confusing now and hence the discussion 
> will be more technical.

Still doesn't address my concerns, namely:
- silently expands the scope of EAPI beyond ebuild contents (which is a
blocker for me)
- doesn't mention compability issues on the dev side (minor)

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

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

[Ciaran McCreesh]

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

On Mon, 31 Dec 2007 15:33:51 +0100
Marius Mauch <genone@gentoo.org> wrote:
> - silently expands the scope of EAPI beyond ebuild contents (which is
> a blocker for me)

That already happened with EAPI 1 and slot deps.

-- 
Ciaran McCreesh

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

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

[Piotr Jaroszyński]

On Monday 31 of December 2007 15:33:51 Marius Mauch wrote:
> Still doesn't address my concerns, namely:
> - silently expands the scope of EAPI beyond ebuild contents (which is a
> blocker for me)

And what is the reason for not doing exactly that? Seems logical to me. And 
btw. slot deps added in EAPI 1 seems to have similiar impact, you can't use 
them in ebuilds using EAPI 0 nor in profiles/.

> - doesn't mention compability issues on the dev side (minor)

Aren't new EAPIs introducing the same problem already? Devs should use up to 
date tools, and especially the devs running some checks on the whole tree.

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

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

[Marius Mauch]

On Mon, 31 Dec 2007 14:40:57 +0000
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Mon, 31 Dec 2007 15:33:51 +0100
> Marius Mauch <genone@gentoo.org> wrote:
> > - silently expands the scope of EAPI beyond ebuild contents (which is
> > a blocker for me)
> 
> That already happened with EAPI 1 and slot deps.

Not really. Just because slot deps are included in EAPI 1 doesn't mean that they have to be supported everywhere. The complete atom specification should be a separate versioned document, and EAPI references version X of it and the profile specification references version Y, simple as that.

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