Re: [gentoo-dev] RFC: future.eclass

2014-11-07 Thread Rich Freeman 
On Thu, Nov 6, 2014 at 5:09 PM, Andreas K. Huettel dilfri...@gentoo.org wrote:
 Am Donnerstag, 6. November 2014, 22:56:21 schrieb Rich Freeman:

 I think we are well-served by taking Ciaran's advice here.  Utility
 eclasses should just passively export functions.  Anything that does
 overrides should really be designed for special situations and not
 widespread use where it would potentially conflict with other eclasses
 that do the same.  So, a KDE all-in-one eclass might not be bad.  A
 perl all-in-one eclass would be more troublesome,

 Bad example. :) We have ca 1800 packages in the portage tree inheriting perl-
 module.eclass and most of them do not declare any phases themselves but just
 inherit eclass phases. Which works fine and reduces most ebuilds to a bare
 minimum.

I don't see perl MODULES as being a bad use of this, but an all-in-one
eclass that was intended for packages that were written (partially or
totally) in perl would not be a good thing IMO.

The problem comes when you get into situations where the perl gurus
wanted a fancy eclass, and the python maintainers wanted a fancy
eclass, and the games maintainers wanted a fancy eclass, and your
package is a game that includes some files written in python and perl.

When you have a bunch of packages that tend to come from the same
upstream with the same development/release/packaging practices then
sure, an all-in-one can make the ebuilds a lot cleaner.

I think we're on the same page in any case.

--
Rich

Re: [gentoo-dev] RFC: future.eclass

2014-11-07 Thread Rich Freeman 
On Thu, Nov 6, 2014 at 5:03 PM, Zac Medico zmed...@gentoo.org wrote:
 On 11/06/2014 01:53 PM, Rich Freeman wrote:
 On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny mgo...@gentoo.org wrote:

 # This eclass contains backports of functions that were accepted
 # by the Council for the EAPI following the EAPI used by ebuild,
 # and can be implemented in pure shell script.

 I'm not sure that I like this sort of a moving-target definition.
 When EAPI6 is out, do you intend to have the eclass die at some point
 for any packages using EAPI5?

 We should be able to simply migrate consumers to the new EAPI, then
 deprecate future.eclass.


Deprecate it?  But what about providing EAPI7 support for EAPI6
packages?  The description doesn't say that the eclass is intended to
provide EAPI6 support for EAPI5 packages - it says that it is intended
to provide EAPIn+1 support for EAPIn packages.

Of course, this approach tends to make the assumption that EAPIs are
orderable, which isn't actually something anybody has committed to as
far as I'm aware.  The next EAPI /could/ be named webapp-1 and only
be used for web applications.  Granted, there have been no plans to
date to deviate from the linear EAPI history we've maintained so far.

I'm still concerned that in general we tend to have packages hang
around at older EAPIs for a long time as it is.  That isn't really a
problem if those EAPIs are stable and supported for a while.  This
seems likely to complicate things.  There is no guarantee that moving
to the actual new EAPI won't break something, and packages that don't
move become blockers for the eclass being able to move on to the next
EAPI.

--
Rich

Re: [gentoo-dev] RFC: future.eclass

2014-11-07 Thread Zac Medico 
On 11/07/2014 03:13 AM, Rich Freeman wrote:
 On Thu, Nov 6, 2014 at 5:03 PM, Zac Medico zmed...@gentoo.org wrote:
 On 11/06/2014 01:53 PM, Rich Freeman wrote:
 On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny mgo...@gentoo.org wrote:

 # This eclass contains backports of functions that were accepted
 # by the Council for the EAPI following the EAPI used by ebuild,
 # and can be implemented in pure shell script.

 I'm not sure that I like this sort of a moving-target definition.
 When EAPI6 is out, do you intend to have the eclass die at some point
 for any packages using EAPI5?

 We should be able to simply migrate consumers to the new EAPI, then
 deprecate future.eclass.

 
 Deprecate it?  But what about providing EAPI7 support for EAPI6
 packages?  The description doesn't say that the eclass is intended to
 provide EAPI6 support for EAPI5 packages - it says that it is intended
 to provide EAPIn+1 support for EAPIn packages.

Okay, then we could number the future eclasses by EAPI. Like
future-eapi-6, future-eapi-7, and so on.

 Of course, this approach tends to make the assumption that EAPIs are
 orderable, which isn't actually something anybody has committed to as
 far as I'm aware.  The next EAPI /could/ be named webapp-1 and only
 be used for web applications.  Granted, there have been no plans to
 date to deviate from the linear EAPI history we've maintained so far.

We could also add a future-eapi-webapp-1 eclass.

 I'm still concerned that in general we tend to have packages hang
 around at older EAPIs for a long time as it is.  That isn't really a
 problem if those EAPIs are stable and supported for a while.  This
 seems likely to complicate things.

Sure, it could. However, it should be pretty manageable if we use a
separate future eclass for each EAPI.

 There is no guarantee that moving
 to the actual new EAPI won't break something, and packages that don't
 move become blockers for the eclass being able to move on to the next
 EAPI.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: future.eclass

2014-11-07 Thread Rich Freeman 
On Fri, Nov 7, 2014 at 1:01 PM, Zac Medico zmed...@gentoo.org wrote:

 I'm still concerned that in general we tend to have packages hang
 around at older EAPIs for a long time as it is.  That isn't really a
 problem if those EAPIs are stable and supported for a while.  This
 seems likely to complicate things.

 Sure, it could. However, it should be pretty manageable if we use a
 separate future eclass for each EAPI.


I am still a bit uneasy, but I definitely agree that if we do this I'd
much rather see a series of versioned eclasses than an eclass whose
functionality changes in place over time.

Ulm's point still exists that technically EAPI6 isn't actually
approved yet, in part because the agreement was that nothing gets
approved for good without a reference implementation in portage.  So,
there is some risk that it could change, which might mean that ebuilds
that use future.eclass would need more work when moving them to an
EAPI that no longer contains the function they call.

That said, the whole point of the council vote was to avoid having the
PM teams spending time on features that were going to get voted out at
the last minute.  Assuming that all goes as planned the actual PMS
vote should be a formality, but you know how plans go...  :)

--
Rich

Re: [gentoo-dev] RFC: future.eclass

2014-11-07 Thread Ulrich Mueller 
 On Fri, 7 Nov 2014, Rich Freeman wrote:

 I am still a bit uneasy, but I definitely agree that if we do this I'd
 much rather see a series of versioned eclasses than an eclass whose
 functionality changes in place over time.

 Ulm's point still exists that technically EAPI6 isn't actually
 approved yet, in part because the agreement was that nothing gets
 approved for good without a reference implementation in portage.  So,
 there is some risk that it could change, which might mean that ebuilds
 that use future.eclass would need more work when moving them to an
 EAPI that no longer contains the function they call.

 That said, the whole point of the council vote was to avoid having the
 PM teams spending time on features that were going to get voted out at
 the last minute.  Assuming that all goes as planned the actual PMS
 vote should be a formality, but you know how plans go...  :)

I had thought that the lesson from premature implementation of the
einstalldocs function in an eclass had been learned. There we have the
problem that the eclass function is incompatible with what will be
implemented in the package manager. Now we will have a third
implementation of einstalldocs, along with a third implementation of
the patch applying function. (The whole point of eapply is that it
will be implemented in the PM; in eclasses we already have epatch
which is more sophisticated.)

Also I still don't see what problem future.eclass would solve. It
doesn't save the EAPI bump, so the maintainer will have to update the
ebuild twice, users will have to rebuild the package twice, and arch
teams will have to stabilise twice.

Besides, an eclass like this would also undermine the council's and QA
team's efforts to keep the number of EAPIs in tree limited.

Ulrich


pgpOCTDmB9yz6.pgp
Description: PGP signature

[gentoo-dev] RFC: future.eclass

2014-11-06 Thread Michał Górny 
Hi,

Please review the attached future.eclass. Long story short, the idea is
to provide some of the EAPI 6 feel to EAPI 5 ebuilds.

Quoting the beginning of the DESCRIPTION:

# This eclass contains backports of functions that were accepted
# by the Council for the EAPI following the EAPI used by ebuild,
# and can be implemented in pure shell script.
#
# The goals of the eclass are to:
# 1. provide wider testing of Portage implementations of the next EAPI
# functions,
# 2. allows developer to use some of the features of the next EAPI
# before it is approved production-ready and implemented in Portage
# for long enough,
# 3. improve EAPI migration time through allowing some of the ebuild
# updates earlier,
# 4. reduce the necessity of inheriting large, complex and frequently
# changing eclasses whenever possible.

and the feature list:

# Currently implemented EAPI 6 features for EAPI 5:
# 1. get_libdir() #463586, simpler than in multilib.eclass;
# 2. einstalldocs() #459862, does not use dohtml as eutils.eclass does;
# 3. eapply() #463768;
# 4. eapply_user() #475288;
# 5. new default src_prepare()  src_install() exported;
# 6. einstall() is banned #524112 [may be non-portable];
# 7. dohtml() is deprecated #520546 [may be non-portable].


-- 
Best regards,
Michał Górny
# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: future.eclass
# @MAINTAINER:
# mgo...@gentoo.org
# @BLURB: backports of functions accepted for the next EAPI
# @DESCRIPTION:
# This eclass contains backports of functions that were accepted
# by the Council for the EAPI following the EAPI used by ebuild,
# and can be implemented in pure shell script.
#
# The goals of the eclass are to:
# 1. provide wider testing of Portage implementations of the next EAPI
# functions,
# 2. allows developer to use some of the features of the next EAPI
# before it is approved production-ready and implemented in Portage
# for long enough,
# 3. improve EAPI migration time through allowing some of the ebuild
# updates earlier,
# 4. reduce the necessity of inheriting large, complex and frequently
# changing eclasses whenever possible.
#
# Please note that the eclass is meant to support the newest EAPI only.
# At the time, this means that EAPI=5 ebuilds will get some EAPI=6
# features through it but EAPI=4 ebuilds are supposed to use EAPI=5
# directly.
#
# If a function declared in the next EAPI collides with eclass-defined
# function (e.g. get_libdir() in EAPI 6 and multilib.eclass),
# the future.eclass version is used whenever it is inherited later.
# Otherwise, the implementation can be accessed using 'future_' prefix.
# It is generally recommended to inherit future after those other
# eclasses, or not inherit those eclasses at all.
#
# Note to future maintainers: please don't add support for new EAPIs
# before the contents of a subsequent EAPI are approved by the Council
# and implemented in Portage.
#
# Currently implemented EAPI 6 features for EAPI 5:
# 1. get_libdir() #463586, simpler than in multilib.eclass;
# 2. einstalldocs() #459862, does not use dohtml as eutils.eclass does;
# 3. eapply() #463768;
# 4. eapply_user() #475288;
# 5. new default src_prepare()  src_install() exported;
# 6. einstall() is banned #524112 [may be non-portable];
# 7. dohtml() is deprecated #520546 [may be non-portable].

if [[ -z ${_FUTURE_ECLASS} ]]; then

case ${EAPI:-0} in
5) ;;
*) die EAPI ${EAPI:-0} is not supported by future.eclass.;;
esac

fi

# (run outside the guard for expectable behavior w/ indirect inherits)

# multilib.eclass collisions
get_libdir() { future_get_libdir ${@}; }
# eutils.eclass collisions
einstalldocs() { future_einstalldocs ${@}; }

EXPORT_FUNCTIONS src_prepare src_install

if [[ -z ${_FUTURE_ECLASS} ]]; then

# 1. NEW FUNCTIONS

# @FUNCTION: get_libdir
# @RETURN: the libdir for the selected ABI
# @DESCRIPTION:
# Return the proper libdir for the selected ABI, fallback to 'lib'.
#
# The implementation is based on the implementation used in econf PMS
# function. However, this one returns 'lib' whenever the econf
# implementation would not pass --libdir.
#
# Note: if multilib.eclass is inherited after future.eclass,
# the implementation can be accessed as future_get_libdir.
future_get_libdir() {
local libdir_var=LIBDIR_${ABI}
local libdir=lib

[[ -n ${ABI}  -n ${!libdir_var} ]]  libdir=${!libdir_var}

echo ${libdir}
}

# @FUNCTION: einstalldocs
# @DESCRIPTION:
# Install documentation using DOCS and HTML_DOCS.
#
# If DOCS is declared and non-empty, all files and directories listed
# in it are installed. The files must exist, otherwise the function
# will fail.
#
# If DOCS is not declared, the files matching patterns given
# in the default EAPI implementation of src_install will be installed.
# If this is undesired, DOCS can be set to empty value to prevent any
# documentation from being installed.
#
# If HTML_DOCS is declared and

Re: [gentoo-dev] RFC: future.eclass

2014-11-06 Thread Ciaran McCreesh 
On Thu, 6 Nov 2014 21:11:03 +0100
Michał Górny mgo...@gentoo.org wrote:
 Please review the attached future.eclass. Long story short, the idea
 is to provide some of the EAPI 6 feel to EAPI 5 ebuilds.

Only if using future.eclass means any other developer automatically has
permission to upgrade your ebuilds to a newer EAPI...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: future.eclass

2014-11-06 Thread Zac Medico 
On 11/06/2014 12:11 PM, Michał Górny wrote:
 # multilib.eclass collisions
 get_libdir() { future_get_libdir ${@}; }
 # eutils.eclass collisions
 einstalldocs() { future_einstalldocs ${@}; }

This collision handling mechanism seems pretty reasonable.
Alternatively, maybe it could die if the functions are already defined,
and advise the developer that future should be inherited later than
multilib and eutils. Is there any reason not to inherit future after
multilib and eutils? I guess the reason would be some dependency on the
old implementations?
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: future.eclass

2014-11-06 Thread Zac Medico 
On 11/06/2014 12:40 PM, Zac Medico wrote:
 On 11/06/2014 12:11 PM, Michał Górny wrote:
 # multilib.eclass collisions
 get_libdir() { future_get_libdir ${@}; }
 # eutils.eclass collisions
 einstalldocs() { future_einstalldocs ${@}; }
 
 This collision handling mechanism seems pretty reasonable.
 Alternatively, maybe it could die if the functions are already defined,
 and advise the developer that future should be inherited later than
 multilib and eutils.

Now I realize that future.eclass has no way of knowing when mutilib or
eutils are inherited later. So, I can't think of a better way to handle
the collisions that what you already have.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: future.eclass

2014-11-06 Thread Zac Medico 
On 11/06/2014 01:11 PM, Zac Medico wrote:
 On 11/06/2014 12:40 PM, Zac Medico wrote:
 On 11/06/2014 12:11 PM, Michał Górny wrote:
 # multilib.eclass collisions
 get_libdir() { future_get_libdir ${@}; }
 # eutils.eclass collisions
 einstalldocs() { future_einstalldocs ${@}; }

 This collision handling mechanism seems pretty reasonable.
 Alternatively, maybe it could die if the functions are already defined,
 and advise the developer that future should be inherited later than
 multilib and eutils.
 
 Now I realize that future.eclass has no way of knowing when mutilib or
 eutils are inherited later. So, I can't think of a better way to handle
 the collisions that what you already have.

Well, I suppose that multilib and eutils could check to see if future
was inherited earlier, and die in that case.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: future.eclass

2014-11-06 Thread Jeroen Roovers 
On Thu, 06 Nov 2014 12:40:33 -0800
Zac Medico zmed...@gentoo.org wrote:

 On 11/06/2014 12:11 PM, Michał Górny wrote:
  # multilib.eclass collisions
  get_libdir() { future_get_libdir ${@}; }
  # eutils.eclass collisions
  einstalldocs() { future_einstalldocs ${@}; }
 
 This collision handling mechanism seems pretty reasonable.
 Alternatively, maybe it could die if the functions are already
 defined, and advise the developer that future should be inherited
 later than multilib and eutils.

I'm not aware of any current definition of order in eclass inheritance.
We sure have issues with inheriting eclasses in a different order giving
different results now. Is this something that's in the works for a
future EAPI, then?


 jer

Re: [gentoo-dev] RFC: future.eclass

2014-11-06 Thread Ciaran McCreesh 
On Thu, 6 Nov 2014 22:32:17 +0100
Jeroen Roovers j...@gentoo.org wrote:
 On Thu, 06 Nov 2014 12:40:33 -0800
 Zac Medico zmed...@gentoo.org wrote:
  On 11/06/2014 12:11 PM, Michał Górny wrote:
   # multilib.eclass collisions
   get_libdir() { future_get_libdir ${@}; }
   # eutils.eclass collisions
   einstalldocs() { future_einstalldocs ${@}; }
  
  This collision handling mechanism seems pretty reasonable.
  Alternatively, maybe it could die if the functions are already
  defined, and advise the developer that future should be inherited
  later than multilib and eutils.
 
 I'm not aware of any current definition of order in eclass
 inheritance. We sure have issues with inheriting eclasses in a
 different order giving different results now. Is this something
 that's in the works for a future EAPI, then?

An EAPI solution to this is hard to work out. It would be much easier if
people just stopped writing clever eclasses and didn't mix utility
functions and phase functions within a single eclass.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: future.eclass

2014-11-06 Thread Zac Medico 
On 11/06/2014 01:32 PM, Jeroen Roovers wrote:
 On Thu, 06 Nov 2014 12:40:33 -0800
 Zac Medico zmed...@gentoo.org wrote:
 
 On 11/06/2014 12:11 PM, Michał Górny wrote:
 # multilib.eclass collisions
 get_libdir() { future_get_libdir ${@}; }
 # eutils.eclass collisions
 einstalldocs() { future_einstalldocs ${@}; }

 This collision handling mechanism seems pretty reasonable.
 Alternatively, maybe it could die if the functions are already
 defined, and advise the developer that future should be inherited
 later than multilib and eutils.
 
 I'm not aware of any current definition of order in eclass inheritance.

Maybe PMS doesn't say anything about the order (yet). However, I'm
fairly sure that all package managers process eclasses in the same order
that they are passed as arguments to inherit. Otherwise, eclasses would
not be able to properly override functions defined by eclasses earlier
in the inherit chain.

In the context of future.eclass, eutils and multilib could simply check
if the relevant functions were defined earlier, and die in that case.

 We sure have issues with inheriting eclasses in a different order giving
 different results now. Is this something that's in the works for a
 future EAPI, then?

No, but as said, I'm fairly sure that all package managers process
eclasses in the same order that they are passed as arguments to inherit.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: future.eclass

2014-11-06 Thread Rich Freeman 
On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny mgo...@gentoo.org wrote:

 # This eclass contains backports of functions that were accepted
 # by the Council for the EAPI following the EAPI used by ebuild,
 # and can be implemented in pure shell script.

I'm not sure that I like this sort of a moving-target definition.
When EAPI6 is out, do you intend to have the eclass die at some point
for any packages using EAPI5?  Or will they work indefinitely, and
then the eclass will behave differently depending on what EAPI is used
by the ebuild calling it?  I can see issues either way (either we're
building a monster eclass that basically replicates half of PMS, or we
start running into migration issues and maybe even breakage of old
systems that aren't updated/etc).

If this were about testing EAPI features prior to implementation in a
limited and short-term scenario I could maybe see this being a
net-positive, but even then we have issues with the eclass changing
when users still have packages using it installed.

I get what you're trying to do, but I'm a little worried that it might
cause as many problems as it solves.

---
Rich

Re: [gentoo-dev] RFC: future.eclass

2014-11-06 Thread Rich Freeman 
On Thu, Nov 6, 2014 at 4:38 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
 On Thu, 6 Nov 2014 22:32:17 +0100
 Jeroen Roovers j...@gentoo.org wrote:
 On Thu, 06 Nov 2014 12:40:33 -0800
 Zac Medico zmed...@gentoo.org wrote:
  On 11/06/2014 12:11 PM, Michał Górny wrote:
   # multilib.eclass collisions
   get_libdir() { future_get_libdir ${@}; }
   # eutils.eclass collisions
   einstalldocs() { future_einstalldocs ${@}; }
 
  This collision handling mechanism seems pretty reasonable.
  Alternatively, maybe it could die if the functions are already
  defined, and advise the developer that future should be inherited
  later than multilib and eutils.

 I'm not aware of any current definition of order in eclass
 inheritance. We sure have issues with inheriting eclasses in a
 different order giving different results now. Is this something
 that's in the works for a future EAPI, then?

 An EAPI solution to this is hard to work out. It would be much easier if
 people just stopped writing clever eclasses and didn't mix utility
 functions and phase functions within a single eclass.


For anybody interested in this the topic came up in the council EAPI
discussions especially on June 17th, and in bug:
https://bugs.gentoo.org/show_bug.cgi?id=422533

I think we are well-served by taking Ciaran's advice here.  Utility
eclasses should just passively export functions.  Anything that does
overrides should really be designed for special situations and not
widespread use where it would potentially conflict with other eclasses
that do the same.  So, a KDE all-in-one eclass might not be bad.  A
perl all-in-one eclass would be more troublesome, especially if KDE
had any packages written in perl.  Just to pick somewhat random and
perhaps not great examples.

--
Rich

Re: [gentoo-dev] RFC: future.eclass

2014-11-06 Thread Zac Medico 
On 11/06/2014 01:53 PM, Rich Freeman wrote:
 On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny mgo...@gentoo.org wrote:

 # This eclass contains backports of functions that were accepted
 # by the Council for the EAPI following the EAPI used by ebuild,
 # and can be implemented in pure shell script.
 
 I'm not sure that I like this sort of a moving-target definition.
 When EAPI6 is out, do you intend to have the eclass die at some point
 for any packages using EAPI5?

We should be able to simply migrate consumers to the new EAPI, then
deprecate future.eclass.

 Or will they work indefinitely, and
 then the eclass will behave differently depending on what EAPI is used
 by the ebuild calling it?  I can see issues either way (either we're
 building a monster eclass that basically replicates half of PMS, or we
 start running into migration issues and maybe even breakage of old
 systems that aren't updated/etc).

Old systems are not a problem, since installed packages always use
serialized eclasses from /var/db/pkg/*/*/environment.bz2.

The biggest problem would be out-of-tree ebuilds (overlays) that
continue to use future.eclass after it's been deprecated.

 If this were about testing EAPI features prior to implementation in a
 limited and short-term scenario I could maybe see this being a
 net-positive, but even then we have issues with the eclass changing
 when users still have packages using it installed.

No, as said, installed packages use serialized eclasses from
/var/db/pkg/*/*/environment.bz2.

 I get what you're trying to do, but I'm a little worried that it might
 cause as many problems as it solves.

Given that old systems aren't a problem, out-of-tree ebuilds are the
main issue that I can think of.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: future.eclass

2014-11-06 Thread Andreas K. Huettel 
Am Donnerstag, 6. November 2014, 22:56:21 schrieb Rich Freeman:
 
 I think we are well-served by taking Ciaran's advice here.  Utility
 eclasses should just passively export functions.  Anything that does
 overrides should really be designed for special situations and not
 widespread use where it would potentially conflict with other eclasses
 that do the same.  So, a KDE all-in-one eclass might not be bad.  A
 perl all-in-one eclass would be more troublesome, 

Bad example. :) We have ca 1800 packages in the portage tree inheriting perl-
module.eclass and most of them do not declare any phases themselves but just 
inherit eclass phases. Which works fine and reduces most ebuilds to a bare 
minimum.

But yes, in general the idea of separating utility eclasses and phase eclasses 
somehow is imho a good one. My personal suggestion would be for a future EAPI 
to only allow export all phases, if necessary autogenerated dummies or 
export no phases.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/



signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] RFC: future.eclass

2014-11-06 Thread Jeroen Roovers 
On Thu, 06 Nov 2014 13:42:43 -0800
Zac Medico zmed...@gentoo.org wrote:

 On 11/06/2014 01:32 PM, Jeroen Roovers wrote:
  I'm not aware of any current definition of order in eclass
  inheritance.
 
 Maybe PMS doesn't say anything about the order (yet). However, I'm
 fairly sure that all package managers process eclasses in the same
 order that they are passed as arguments to inherit. Otherwise,
 eclasses would not be able to properly override functions defined by
 eclasses earlier in the inherit chain.

If the order is important, then the ebuild should call each phase or
utility function explicitly. Expecting the order of inheritance to
convey the same thing instead of making explicit calls might work from
the package manager's perspective, but the ebuild writer is lost in the
woods. With that in mind we might argue that a change in the order of
inheritance should never cause a different outcome.

 In the context of future.eclass, eutils and multilib could simply
 check if the relevant functions were defined earlier, and die in that
 case.

Would the bash internal `readonly -f' work for that?

  We sure have issues with inheriting eclasses in a different order
  giving different results now. Is this something that's in the works
  for a future EAPI, then?
 
 No, but as said, I'm fairly sure that all package managers process
 eclasses in the same order that they are passed as arguments to
 inherit.

Well, that's convenient but you should probably not start relying on
it now. In that case we might want to discuss inheriting in
alphabetical order and numbering the eclasses cleverly, too. Or rename
this one to zfuture.eclass.


 jer

Re: [gentoo-dev] RFC: future.eclass

2014-11-06 Thread Ciaran McCreesh 
On Thu, 06 Nov 2014 13:42:43 -0800
Zac Medico zmed...@gentoo.org wrote:
 Maybe PMS doesn't say anything about the order (yet).

But it does. It says parameters are considered in order.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: future.eclass

2014-11-06 Thread Zac Medico 
On 11/06/2014 02:16 PM, Jeroen Roovers wrote:
 On Thu, 06 Nov 2014 13:42:43 -0800
 Zac Medico zmed...@gentoo.org wrote:
 
 On 11/06/2014 01:32 PM, Jeroen Roovers wrote:
 I'm not aware of any current definition of order in eclass
 inheritance.

 Maybe PMS doesn't say anything about the order (yet). However, I'm
 fairly sure that all package managers process eclasses in the same
 order that they are passed as arguments to inherit. Otherwise,
 eclasses would not be able to properly override functions defined by
 eclasses earlier in the inherit chain.
 
 If the order is important, then the ebuild should call each phase or
 utility function explicitly. Expecting the order of inheritance to
 convey the same thing instead of making explicit calls might work from
 the package manager's perspective, but the ebuild writer is lost in the
 woods. With that in mind we might argue that a change in the order of
 inheritance should never cause a different outcome.
 
 In the context of future.eclass, eutils and multilib could simply
 check if the relevant functions were defined earlier, and die in that
 case.
 
 Would the bash internal `readonly -f' work for that?

Maybe, but the error message would be cryptic. I was thinking something
like this:

declare -F get_libdir /dev/null  \
die multilib.eclass must be inherited before future.eclass

 We sure have issues with inheriting eclasses in a different order
 giving different results now. Is this something that's in the works
 for a future EAPI, then?

 No, but as said, I'm fairly sure that all package managers process
 eclasses in the same order that they are passed as arguments to
 inherit.
 
 Well, that's convenient but you should probably not start relying on
 it now.

I think it would be a fine assumption, and Ciaran has noted that PMS
already specifies that inherit parameters are considered in order.

 In that case we might want to discuss inheriting in
 alphabetical order and numbering the eclasses cleverly, too. Or rename
 this one to zfuture.eclass.

I understand your intentions, but I don't think that's the right
solution. I agree with Ciaran's assertion that it would be much easier
if people just stopped writing clever eclasses and didn't mix utility
functions and phase functions within a single eclass.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFC: future.eclass

2014-11-06 Thread Ulrich Mueller 
 On Thu, 6 Nov 2014, Michał Górny wrote:

 Please review the attached future.eclass. Long story short, the idea
 is to provide some of the EAPI 6 feel to EAPI 5 ebuilds.

I don't like this idea at all. We shouldn't anticipate EAPI 6 features
in an eclass before the spec is final and has been approved by the
council.

If the purpose of this is testing the new feature, then this should be
done in an overlay.

Ulrich


pgpoX1C7TxljG.pgp
Description: PGP signature