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
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
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
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
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
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
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
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
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.
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
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
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
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() {
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
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:
#
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.
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
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
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
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).
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
21 matches
Mail list logo
