Gentoo Archives: gentoo-dev

From: Francesco Riosa <vivo75@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds
Date: Thu, 29 Dec 2011 10:50:21
In Reply to: Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds by Brian Harring
2011/12/29 Brian Harring <ferringb@×××××.com>:
> 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.