Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] extending existing EAPI semantics
Date: Wed, 11 Jun 2008 02:56:34
Message-Id: 20080611025622.GA9494@seldon.metaweb.com
1 Bit curious what folks opinions are re: conversion of eapi
2 requirements into a function, instead of a var. Essentially,
3 currently-
4
5 """
6 #my ebuild.
7 EAPI=1
8 inherit blah
9 DEPEND=monkey
10
11 funcs_and_such(){:;}
12
13 """
14
15 pros:
16 * simple, and was enough to get EAPI off the ground w/out massive
17 fighting (at least not WW3 level fighting)
18 * works fine for metadata key level changes, function changes, etc.
19 I'm aware folks have stated "if DEPENDS changes, it won't be able to
20 handle it"- they're frankly wrong, they're confusing that post
21 sourcing EAPI is checked, *then* if EAPI is supported the metadata is
22 handled, else the manager is signaled that an unknown eapi was
23 encountered (essentially). Continuing...
24
25 cons:
26 * EAPI var must be set effectively before any invocations occur.
27 * global scope invocations (inherit) must be eapi aware;
28 * future additions to global scope invocations (say elib) will result
29 in an error spat by bash ("elib wasn't found").
30 * bash specific (which personally is fine to me, an ebuild is bash).
31 * doesn't address versioning changes.
32
33 Converting it into
34
35 """
36 #my ebuild.
37 eapi 1
38 inherit blah
39 DEPEND=monkey
40
41 funcs_and_such(){:;}
42
43 """
44
45 with eapi effectively being
46
47 eapi() {
48 if [ "$1" == 1 ] || [ "$1" == 0 ];
49 return # we know this eapi, can handle it
50 fi
51 die "unsupported eapi $1"
52 }
53
54 pros:
55 * same benefits as preexisting var approach.
56 * via conversion to invocation instead of var setting (which is
57 untrappable), it's possible to bail the rest of the sourcing, thus
58 preventing any error msgs for unknown global invocations (elib fex).
59 * easy to shoehorn in for any profile.bashrc compliant manager
60 (portage/pkgcore); realize paludis is left out here (via it
61 intentionally being left out of PMS atm by ciaran), but
62 profile.bashrc *is* used by ebuild devs, thus it's a viable course (I
63 don't see profile.bashrc ever going away basically).
64
65 cons:
66 * must be the first invocation.
67 * bash specific (again, ebuild is bash, new format can do things
68 w/out having to worry about backwards compatibility).
69 * doesn't address versioning changes.
70
71
72 Basically, the proposal is an minor tweak of existing support- it has
73 the benefit of avoiding the filename complaints from folks and
74 addressing the usual "global scope invocation will breakzor in later
75 versions" complaint from paludis folk.
76
77 It doesn't particularly provide for people shoving new versioning
78 components in, but frankly that's fine due to the mess having
79 versioning rules bound to EAPI would entail.
80
81 After comments from folks, although if a responder is going to state
82 "filename is better!" skip it please, I already pointed out the diffs
83 (meaning bluntly, kindly skip repeating what has already been said).
84
85 Cheers
86 ~harring

Replies

Subject Author
Re: [gentoo-dev] extending existing EAPI semantics Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>