Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

[Ian Stakenvicius <axs@gentoo.org>]

-----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-----