Gentoo Archives: gentoo-dev

From: Jeroen Roovers <jer@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds
Date: Thu, 29 Dec 2011 15:29:26
In Reply to: Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds by Brian Harring
On Wed, 28 Dec 2011 19:36:01 -0800
Brian Harring <ferringb@×××××.com> wrote:

> 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.
I agree with nearly all of that: introducing changes to an eclass usually means going through the whole tree and fixing what breaks. That's a lot more easy to fix than adding more layers of indirection based on a variable's value and adjusting the value according to the time the ebuild was written versus when the eclass was changed.
> 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.
Last time I took tranquilisers and set myself up to read python.eclass, I found that it still doesn't break at 80 characters. Apparently even that can't be fixed in a timely fashion. Assing even more layers of mystification like: if [[ PYTHON_ECLASS_API = 2 ]]; then python_pkg_setup() { or even: python_pkg_setup() { if [[ PYTHON_ECLASS_API = 2 ]]; then would be insane, in my opinion. Also, from the perspective of an ebuild writer, setting PYTHON_ECLASS_API=2 inherit python would be meaningless lacking a very clear description of what the number 2 means. jer