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
Message-Id: CAD6zcDykus1yZr=CT2iaav32PQXMLYL9irntp0QudXr_4Oz0wA@mail.gmail.com
In Reply to: Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds by Brian Harring
1 2011/12/29 Brian Harring <ferringb@×××××.com>:
2 > On Thu, Dec 29, 2011 at 02:37:07AM +0000, Francesco Riosa wrote:
3 >> 2011/12/28 Zac Medico <zmedico@g.o>:
4 >> > On 12/28/2011 05:12 AM, Francesco Riosa wrote:
5 >> >> Seem to me that append a time slice to the function, in the name or as
6 >> >> a parent function that call the underling function can solve most of
7 >> >> the versioning/deprecation problems
8 >> >
9 >> > I've overheard Arfrever discussing a similar approach in funtoo's irc
10 >> > channel, where the ebuild would set a variable prior to inherit if it
11 >> > wants to use a specific eclass API. For the python eclass, he's planning
12 >> > to have ebuilds set the PYTHON_ECLASS_API variable to use the new API.
13 >> > When the variable is unset, the eclass will default to the older API.
14 >>
15 >> There is a fundamental difference, with "timeslices" it's not the
16 >> ebuild that select the implementation but the point in time it's used,
17 >> or the user forcing a fake time. From what I've read Artfever approach
18 >> require changes in every ebuild and keeping old functions forever. On
19 >> the other hand it may be risky to change the preferred interface from
20 >> the eclass and not the ebuild.
21 >
22 > Respectfully, the proposals thus far (including python eclass bit) are
23 > going in the opposite direction of maintainability, simplicity,
24 > robustness.
25 >
26 > People have problems as is dealing w/ eclasses changing and their
27 > dependencies in external repositories not being updated; this
28 > complicates that issue and introduces the same potential into
29 > gentoo-x86 itself.  That's not beneficial.
30 >
31 > Thing to keep in mind beyond the potential for confusion the proposals
32 > entail were they implemented, is the implementation itself.
33 > Timeslices?  python eclass api versions (when people have problems
34 > figuring out the existing, *singular* version)?  These things aren't
35 > going to be simple which means more than likely, they're going to
36 > break, and more than likely it's going to be a PITA to maintain it.
37 >
38 > Per the norm, I could be wrong, but reading these proposals, they
39 > really feel like they need to revisit the notion of
40 > maintainability/robustness as an actual full fledged implementation,
41 > beyond the (admittedly semi nifty) notion of versioned apis.
42 >
43 > My 2 cents, hopefully not at my usual offensive level-
44 > ~harring
45 >
46 yeah, after a good sleep the problems of this approach are more clear,
47 it's a pity, it seemed really bright while eating my spaghetti.