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