Gentoo Archives: gentoo-dev

From: Ian Stakenvicius <axs@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] New Eclasses: postgres and postgres-multi
Date: Fri, 15 Jan 2016 17:44:04
Message-Id: 56992FD6.9000806@gentoo.org
In Reply to: Re: [gentoo-dev] New Eclasses: postgres and postgres-multi by "Aaron W. Swenson"
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA256
3
4 On 15/01/16 11:43 AM, Aaron W. Swenson wrote:
5 > On 2016-01-13 11:11, Ian Stakenvicius wrote:
6 >> The work looks really good, but I noticed that postgres-multi
7 >> determins the variants to build against based on what's
8 >> installed on disk via checking eselect.. I think it'd likely
9 >> be better to instead have proper dependencies based on USE,
10 >> much like how the python and ABI_* multibuilds work. That
11 >> would make the installations as well as the dependencies be
12 >> determinstic rather than dynamic, which should support binpkgs
13 >> -much- better (among other things).
14 >>
15 >> The "|| ( postgresql:${SLOT1}= postgresql:${SLOT2}= ...)"
16 >> RDEPEND that postgres.eclass works out is a little sketchy
17 >> IMO, unfortunately, as the behaviour that occurs when more than
18 >> one of those slots are installed is afaik a little unstable --
19 >> in theory, changes (including removal) of any of the options
20 >> should trigger a rebuild but I don't know if it does, and I'm
21 >> fairly certain that a simple --unmerge doesn't trigger a
22 >> rebuild. All of that goes away if you perform non-OR
23 >> dependency via use flags.
24 >>
25 >> The drawback of course is yet another USE_EXPAND, or at least
26 >> a bunch of rather long use flags, that will need setting by the
27 >> user.
28 >
29 > What if I made a small adjustment to the DEPEND building like
30 > so:
31 >
32 > - POSTGRES_DEP="|| (" + POSTGRES_REQ_USE=" || (" for slot in
33 > "${POSTGRES_COMPAT[@]}" ; do + IUSE+=" postgres_${slot}" +
34 > POSTGRES_REQ_USE+=" postgres_${slot}" + + ! use
35 > "postgres_${slot/_/.}" && continue POSTGRES_DEP+="
36 > dev-db/postgresql:${slot}=" declare -p POSTGRES_USEDEP
37 > &>/dev/null && \ POSTGRES_DEP+="[${POSTGRES_USEDEP}]" done -
38 > POSTGRES_DEP+=" )" + POSTGRES_REQ_USE=" )"
39 >
40 > I'll have to change from listing the slots in POSTGRES_COMPAT
41 > from N.N to N_N, but that's not terribly difficult given the one
42 > ebuild I have it in.
43 >
44 > Is this a change that would require a USE_EXPAND? I know I'll
45 > have to document the USE flags globally.
46 >
47
48
49 A USE_EXPAND isn't necessary, all that provides is a way to group a
50 set of use flags with a prefix and hide the prefix from end-users
51 for cosmetic purposes.
52
53 As for the patch, you can't determine RDEPEND (ie POSTGRES_DEP)
54 dynamically like that based on what use flags are being set, in
55 global scope -- its a runtime vs metadata-generation-time issue.
56 Changing it to this would work though:
57
58
59 > - ! use "postgres_${slot/_/.}" && continue + POSTGRES_DEP+="
60 > postgres_${slot}? (" POSTGRES_DEP+=" dev-db/postgresql:${slot}="
61 > declare -p POSTGRES_USEDEP &>/dev/null && \
62 > POSTGRES_DEP+="[${POSTGRES_USEDEP}]" + POSTGRES_DEP+=" )"
63
64
65
66 The main issue I still saw though was this, in postgres-multi.eclass:
67
68 > # @FUNCTION: postgres-multi_pkg_setup # @USAGE:
69 > postgres-multi_pkg_setup # @DESCRIPTION: # Initialize internal
70 > environment variable(s). postgres-multi_pkg_setup() { local
71 > all_slots=$(eselect --brief postgresql list) local user_slot
72 >
73 > for user_slot in "${POSTGRES_COMPAT[@]}"; do has "${user_slot}"
74 > ${all_slots} && \ _POSTGRES_UNION_SLOTS+=( "${user_slot}" ) done
75 >
76 > elog "Multibuild variants: ${_POSTGRES_UNION_SLOTS[@]}" }
77
78
79 ..which, if i'm interpreting correctly, is what causes the postgres
80 extension to only be installed against what's on disk. Likely that
81 should be changed to build the list off of whatever postgres_[SLOT]
82 use flags are enabled.
83
84
85 -----BEGIN PGP SIGNATURE-----
86 Version: GnuPG v2
87
88 iF4EAREIAAYFAlaZL9YACgkQAJxUfCtlWe0sJwD+J6+gPdBLxflwrOmKduu820Kh
89 psoQz7x3RxR4ZlZn0tcBAIHgwQcUrvac+pXt8YrgdQe1WsUwEhbtq3UEuL00LZBl
90 =Qr5F
91 -----END PGP SIGNATURE-----

Replies

Subject Author
Re: [gentoo-dev] New Eclasses: postgres and postgres-multi Ian Stakenvicius <axs@g.o>
Re: [gentoo-dev] New Eclasses: postgres and postgres-multi "Aaron W. Swenson" <titanofold@g.o>