-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 15/01/16 11:43 AM, Aaron W. Swenson wrote:
> On 2016-01-13 11:11, Ian Stakenvicius wrote:
>> The work looks really good, but I noticed that postgres-multi
>> determins the variants to build against based on what's
>> installed on disk via checking eselect.. I think it'd likely
>> be better to instead have proper dependencies based on USE,
>> much like how the python and ABI_* multibuilds work. That
>> would make the installations as well as the dependencies be
>> determinstic rather than dynamic, which should support binpkgs
>> -much- better (among other things).
>>
>> The "|| ( postgresql:${SLOT1}= postgresql:${SLOT2}= ...)"
>> RDEPEND that postgres.eclass works out is a little sketchy
>> IMO, unfortunately, as the behaviour that occurs when more than
>> one of those slots are installed is afaik a little unstable --
>> in theory, changes (including removal) of any of the options
>> should trigger a rebuild but I don't know if it does, and I'm
>> fairly certain that a simple --unmerge doesn't trigger a
>> rebuild. All of that goes away if you perform non-OR
>> dependency via use flags.
>>
>> The drawback of course is yet another USE_EXPAND, or at least
>> a bunch of rather long use flags, that will need setting by the
>> user.
>
> What if I made a small adjustment to the DEPEND building like
> so:
>
> - POSTGRES_DEP="|| (" + POSTGRES_REQ_USE=" || (" for slot in
> "${POSTGRES_COMPAT[@]}" ; do + IUSE+=" postgres_${slot}" +
> POSTGRES_REQ_USE+=" postgres_${slot}" + + ! use
> "postgres_${slot/_/.}" && continue POSTGRES_DEP+="
> dev-db/postgresql:${slot}=" declare -p POSTGRES_USEDEP
> &>/dev/null && \ POSTGRES_DEP+="[${POSTGRES_USEDEP}]" done -
> POSTGRES_DEP+=" )" + POSTGRES_REQ_USE=" )"
>
> I'll have to change from listing the slots in POSTGRES_COMPAT
> from N.N to N_N, but that's not terribly difficult given the one
> ebuild I have it in.
>
> Is this a change that would require a USE_EXPAND? I know I'll
> have to document the USE flags globally.
>
A USE_EXPAND isn't necessary, all that provides is a way to group a
set of use flags with a prefix and hide the prefix from end-users
for cosmetic purposes.
As for the patch, you can't determine RDEPEND (ie POSTGRES_DEP)
dynamically like that based on what use flags are being set, in
global scope -- its a runtime vs metadata-generation-time issue.
Changing it to this would work though:
> - ! use "postgres_${slot/_/.}" && continue +
> POSTGRES_DEP+="
> postgres_${slot}? (" POSTGRES_DEP+=" dev-db/postgresql:${slot}="
> declare -p POSTGRES_USEDEP &>/dev/null && \
> POSTGRES_DEP+="[${POSTGRES_USEDEP}]" + POSTGRES_DEP+=" )"
The main issue I still saw though was this, in postgres-multi.eclass:
> # @FUNCTION: postgres-multi_pkg_setup # @USAGE:
> postgres-multi_pkg_setup # @DESCRIPTION: # Initialize internal
> environment variable(s). postgres-multi_pkg_setup() { local
> all_slots=$(eselect --brief postgresql list) local user_slot
>
> for user_slot in "${POSTGRES_COMPAT[@]}"; do has "${user_slot}"
> ${all_slots} && \ _POSTGRES_UNION_SLOTS+=( "${user_slot}" ) done
>
> elog "Multibuild variants: ${_POSTGRES_UNION_SLOTS[@]}" }
..which, if i'm interpreting correctly, is what causes the postgres
extension to only be installed against what's on disk. Likely that
should be changed to build the list off of whatever postgres_[SLOT]
use flags are enabled.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iF4EAREIAAYFAlaZL9YACgkQAJxUfCtlWe0sJwD+J6+gPdBLxflwrOmKduu820Kh
psoQz7x3RxR4ZlZn0tcBAIHgwQcUrvac+pXt8YrgdQe1WsUwEhbtq3UEuL00LZBl
=Qr5F
-----END PGP SIGNATURE-----
