Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Francesco Riosa <vivo75@...>
Subject: Re: Versioning of eclasses and possibly functions inside ebuilds
Date: Thu, 29 Dec 2011 11:49:32 +0100
2011/12/29 Brian Harring <ferringb@...>:
> On Thu, Dec 29, 2011 at 02:37:07AM +0000, Francesco Riosa wrote:
>> 2011/12/28 Zac Medico <zmedico@g.o>:
>> > On 12/28/2011 05:12 AM, Francesco Riosa wrote:
>> >> Seem to me that append a time slice to the function, in the name or as
>> >> a parent function that call the underling function can solve most of
>> >> the versioning/deprecation problems
>> >
>> > I've overheard Arfrever discussing a similar approach in funtoo's irc
>> > channel, where the ebuild would set a variable prior to inherit if it
>> > wants to use a specific eclass API. For the python eclass, he's planning
>> > to have ebuilds set the PYTHON_ECLASS_API variable to use the new API.
>> > When the variable is unset, the eclass will default to the older API.
>>
>> There is a fundamental difference, with "timeslices" it's not the
>> ebuild that select the implementation but the point in time it's used,
>> or the user forcing a fake time. From what I've read Artfever approach
>> require changes in every ebuild and keeping old functions forever. On
>> the other hand it may be risky to change the preferred interface from
>> the eclass and not the ebuild.
>
> Respectfully, the proposals thus far (including python eclass bit) are
> going in the opposite direction of maintainability, simplicity,
> robustness.
>
> People have problems as is dealing w/ eclasses changing and their
> dependencies in external repositories not being updated; this
> complicates that issue and introduces the same potential into
> gentoo-x86 itself.  That's not beneficial.
>
> Thing to keep in mind beyond the potential for confusion the proposals
> entail were they implemented, is the implementation itself.
> Timeslices?  python eclass api versions (when people have problems
> figuring out the existing, *singular* version)?  These things aren't
> going to be simple which means more than likely, they're going to
> break, and more than likely it's going to be a PITA to maintain it.
>
> Per the norm, I could be wrong, but reading these proposals, they
> really feel like they need to revisit the notion of
> maintainability/robustness as an actual full fledged implementation,
> beyond the (admittedly semi nifty) notion of versioned apis.
>
> My 2 cents, hopefully not at my usual offensive level-
> ~harring
>
yeah, after a good sleep the problems of this approach are more clear,
it's a pity, it seemed really bright while eating my spaghetti.


References:
Versioning of eclasses and possibly functions inside ebuilds
-- Francesco Riosa
Re: Versioning of eclasses and possibly functions inside ebuilds
-- Zac Medico
Re: Versioning of eclasses and possibly functions inside ebuilds
-- Francesco Riosa
Re: Versioning of eclasses and possibly functions inside ebuilds
-- Brian Harring
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Versioning of eclasses and possibly functions inside ebuilds
Next by thread:
Re: Versioning of eclasses and possibly functions inside ebuilds
Previous by date:
Re: Versioning of eclasses and possibly functions inside ebuilds
Next by date:
Re: Versioning of eclasses and possibly functions inside ebuilds


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.