-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 15/01/16 12:43 PM, Ian Stakenvicius wrote:
> 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.
>
>
>
I did up a pull request with my change idea; haven't tested it yet
so there may be issues, but i think the diff from the PR would be
easier to understand than the messy code i tried to put in this email.
https://github.com/titanofold/titanofold-gentoo-x86/pull/6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iF4EAREIAAYFAlaZOeIACgkQAJxUfCtlWe1w1QEAx6jdKVtU0EU0NQvfmiJlDUcJ
LSFq+p+vJ0DUqkcwH1EA/idGolmJC/l5cmKlfVU9QMS1hkZUINHCtAV1202RdDrb
=lkja
-----END PGP SIGNATURE-----
