Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds

[Francesco Riosa <vivo75@gmail.com>]

2011/12/29 Brian Harring <ferringb@gmail.com>:
> On Thu, Dec 29, 2011 at 02:37:07AM +0000, Francesco Riosa wrote:
>> 2011/12/28 Zac Medico <zmedico@gentoo.org>:
>> > 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.