> 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
On Fri, Nov 7, 2014 at 1:01 PM, Zac Medico 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 thing
On 11/07/2014 03:13 AM, Rich Freeman wrote:
> On Thu, Nov 6, 2014 at 5:03 PM, Zac Medico wrote:
>> On 11/06/2014 01:53 PM, Rich Freeman wrote:
>>> On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny wrote:
# This eclass contains backports of functions that were accepted
# by the Council f
On Thu, Nov 6, 2014 at 5:03 PM, Zac Medico wrote:
> On 11/06/2014 01:53 PM, Rich Freeman wrote:
>> On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny wrote:
>>>
>>> # This eclass contains backports of functions that were accepted
>>> # by the Council for the EAPI following the EAPI used by ebuild,
>>>
On Thu, Nov 6, 2014 at 5:09 PM, Andreas K. Huettel 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 b
> 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
On 11/06/2014 02:16 PM, Jeroen Roovers wrote:
> On Thu, 06 Nov 2014 13:42:43 -0800
> Zac Medico 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). How
On Thu, 06 Nov 2014 13:42:43 -0800
Zac Medico 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 Thu, 06 Nov 2014 13:42:43 -0800
Zac Medico 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 proc
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
On 11/06/2014 01:53 PM, Rich Freeman wrote:
> On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny 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 no
On Thu, Nov 6, 2014 at 4:38 PM, Ciaran McCreesh
wrote:
> On Thu, 6 Nov 2014 22:32:17 +0100
> Jeroen Roovers wrote:
>> On Thu, 06 Nov 2014 12:40:33 -0800
>> Zac Medico wrote:
>> > On 11/06/2014 12:11 PM, Michał Górny wrote:
>> > > # multilib.eclass collisions
>> > > get_libdir() { future_get_libd
On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny 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 defini
On 11/06/2014 01:32 PM, Jeroen Roovers wrote:
> On Thu, 06 Nov 2014 12:40:33 -0800
> 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_einsta
On Thu, 6 Nov 2014 22:32:17 +0100
Jeroen Roovers wrote:
> On Thu, 06 Nov 2014 12:40:33 -0800
> 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(
On Thu, 06 Nov 2014 12:40:33 -0800
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 mechani
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 "${@}"; }
>>
>
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 r
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 Thu, 6 Nov 2014 21:11:03 +0100
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.
Only if using future.eclass means any other developer automatically has
permission to upgrade your ebuilds to a n
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 eb
21 matches
Mail list logo
