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

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

[Aaron W. Swenson]

[-- Attachment #1.1: Type: text/plain, Size: 879 bytes --]

There are several ebuilds that repeat the same checks and need to
perform the same duties when it comes to working with PostgreSQL. For
example, making sure the users' currently slot is compatible with the
ebuild requirements. postgres.eclass addresses this and has
additional conveniences to build a dependency string and add a new user
into the postgres system group.

Additionally, as most of you are aware, we have a slot capable
dev-db/postgresql. There is some difficulty that needed to be resolved
so that extensions could also be installed into multiple slots, which is
addressed by postgres-multi.eclass.

I've an overlay at:
https://github.com/titanofold/titanofold-gentoo-x86

With the pgsql-eclass branch containing the eclass and a postgres-multi
enabled PostGIS.

Naturally, the eclasses work for me, so far.

For your convenience, I've also attached the eclasses.

[-- Attachment #1.2: postgres-multi.eclass --]
[-- Type: text/plain, Size: 3715 bytes --]

# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

inherit multibuild postgres
EXPORT_FUNCTIONS pkg_setup src_prepare src_compile src_install src_test


# @ECLASS: postgres-multi
# @MAINTAINER:
# PostgreSQL <pgsql-bugs@gentoo.org>
# @AUTHOR: Aaron W. Swenson <titanofold@gentoo.org>
# @BLURB: An eclass for PostgreSQL-related packages with default functions
# @DESCRIPTION:
# postgres-multi enables ebuilds, particularly PostgreSQL extensions, to
# build against any and all compatible, installed PostgreSQL
# slots. Additionally exports default functions.


case ${EAPI:-0} in
  0|1|2|3|4) die "postgres-multi.eclass requires EAPI 5 or higher" ;;
  *) ;;
esac


# @ECLASS-VARIABLE: POSTGRES_COMPAT
# @REQUIRED
# @DESCRIPTION:
# A Bash array containing a list of compatible PostgreSQL slots as
# defined by the developer.
if ! declare -p POSTGRES_COMPAT &>/dev/null; then
	die 'Required variable POSTGRES_COMPAT not declared.'
fi

# @ECLASS-VARIABLE: _POSTGRES_UNION_SLOTS
# @INTERNAL
# @DESCRIPTION:
# A Bash array containing the union set of available slots installed on the
# system that are also in POSTGRES_COMPAT.
export _POSTGRES_UNION_SLOTS=( )

# @FUNCTION _postgres-multi_multibuild_wrapper
# @INTERNAL
# @USAGE: _postgres-multi_multibuild_wrapper <command> [<arg> ...]
# @DESCRIPTION:
# For the given variant, set the values of the PG_SLOT and PG_CONFIG
# environment variables accordingly and replace any appearance of
# @PG_SLOT@ in the command and arguments with value of ${PG_SLOT}.
_postgres-multi_multibuild_wrapper() {
	debug-print-function ${FUNCNAME} "${@}"
	export PG_SLOT=${MULTIBUILD_VARIANT}
	export PG_CONFIG=$(which pg_config${MULTIBUILD_VARIANT//./})
	$(echo "${@}" | sed "s/@PG_SLOT@/${PG_SLOT}/g")
}

# @FUNCTION: postgres-multi_foreach
# @USAGE: postgres-multi_foreach <command> <arg> [<arg> ...]
# @DESCRIPTION:
# Run the given command in the package's source directory for each
# installed PostgreSQL slot. Any appearance of @PG_SLOT@ in the command
# or arguments will be substituted with the slot of the current
# iteration.
postgres-multi_foreach() {
	local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[@]}")

	multibuild_foreach_variant \
		_postgres-multi_multibuild_wrapper run_in_build_dir ${@}
}

# @FUNCTION: postgres-multi_forbest
# @USAGE: postgres-multi_forbest <command> <arg> [<arg> ...]
# @DESCRIPTION:
# Run the given command in the package's source directory for the best
# installed, compatible PostgreSQL slot. Any appearance of @PG_SLOT@ in
# the command or arguments will be substituted with the matching slot.
postgres-multi_forbest() {
	# POSTGRES_COMPAT is reverse sorted once in postgres.eclass so
	# element 0 has the highest slot version.
	local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[0]}")

	multibuild_foreach_variant \
		_postgres-multi_multibuild_wrapper run_in_build_dir ${@}
}

# @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[@]}"
}

postgres-multi_src_prepare() {
	local MULTIBUILD_VARIANT
	local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[@]}")
	multibuild_copy_sources
}

postgres-multi_src_compile() {
	postgres-multi_foreach emake
}

postgres-multi_src_install() {
	postgres-multi_foreach emake install DESTDIR="${D}"
}

postgres-multi_src_test() {
	postgres-multi_foreach emake installcheck
}

[-- Attachment #1.3: postgres.eclass --]
[-- Type: text/plain, Size: 3084 bytes --]

# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

inherit user

# @ECLASS: postgres
# @MAINTAINER:
# PostgreSQL <pgsql-bugs@gentoo.org>
# @AUTHOR: Aaron W. Swenson <titanofold@gentoo.org>
# @BLURB: An eclass for PostgreSQL-related packages
# @DESCRIPTION:
# This eclass provides common utility functions that many
# PostgreSQL-related packages perform, such as checking that the
# currently selected PostgreSQL slot is within a range, adding a system
# user to the postgres system group, and generating dependencies.


case ${EAPI:-0} in
  0|1|2|3|4) die "postgres.eclass requires EAPI 5 or higher" ;;
  *) ;;
esac


# @ECLASS-VARIABLE: POSTGRES_COMPAT
# @DESCRIPTION:
# A Bash array containing a list of compatible PostgreSQL slots as
# defined by the developer.

# @ECLASS-VARIABLE: POSTGRES_DEP
# @DESCRIPTION:
# An automatically generated dependency string suitable for use in
# DEPEND and RDEPEND declarations.

# @ECLASS-VARIABLE: POSTGRES_USEDEP
# @DESCRIPTION:
# Add the given, without brackets, 2-Style and/or 4-Style use
# dependencies to POSTGRES_DEP

if declare -p POSTGRES_COMPAT &> /dev/null ; then
	# Reverse sort the given POSTGRES_COMPAT so that the most recent
	# slot is preferred over an older slot.
	readarray -t POSTGRES_COMPAT < <(printf '%s\n' "${POSTGRES_COMPAT[@]}" | sort -nr)

	POSTGRES_DEP="|| ("
	for slot in "${POSTGRES_COMPAT[@]}" ; do
		POSTGRES_DEP+=" dev-db/postgresql:${slot}="
		declare -p POSTGRES_USEDEP &>/dev/null && \
			POSTGRES_DEP+="[${POSTGRES_USEDEP}]"
	done
	POSTGRES_DEP+=" )"
else
	POSTGRES_DEP="dev-db/postgresql"
	declare -p POSTGRES_USEDEP &>/dev/null && \
		POSTGRES_DEP+="[${POSTGRES_USEDEP}]"
fi


# @FUNCTION: postgres_check_slot
# @DESCRIPTION:
# Verify that the currently selected PostgreSQL slot is set to one of
# the slots defined in POSTGRES_COMPAT. Automatically dies unless a
# POSTGRES_COMPAT slot is selected. Should be called in pkg_pretend().
postgres_check_slot() {
	if ! declare -p POSTGRES_COMPAT &>/dev/null; then
		die 'POSTGRES_COMPAT not declared.'
	fi

	# Don't die because we can't run postgresql-config during pretend.
	[[ "$EBUILD_PHASE" = "pretend" && -z "$(which postgresql-config 2> /dev/null)" ]] \
		&& return 0

	if has $(postgresql-config show 2> /dev/null) "${POSTGRES_COMPAT[@]}"; then
		return 0
	else
		eerror "PostgreSQL slot must be set to one of: "
		eerror "    ${POSTGRES_COMPAT[@]}"
		die "Incompatible PostgreSQL slot eselected"
	fi
}

# @FUNCTION: postgres_new_user
# @DESCRIPTION:
# Creates the "postgres" system group and user -- which is separate from
# the database user -- in addition to the developer defined user. Takes
# the same arguments as "enewuser".
postgres_new_user() {
	enewgroup postgres 70
	enewuser postgres 70 /bin/bash /var/lib/postgresql postgres

	if [[ $# -gt 0 ]] ; then
		if [[ "$1" = "postgres" ]] ; then
			ewarn "Username 'postgres' implied, skipping"
		else
			local groups=$5
			[[ -n "${groups}" ]] && groups+=",postgres" || groups="postgres"
			enewuser $1 $2 $3 $4 ${groups}
		fi
	fi
}

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 345 bytes --]

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

[Manuel Rüger]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

On 12.01.2016 20:22, Aaron W. Swenson wrote:
> There are several ebuilds that repeat the same checks and need to
> perform the same duties when it comes to working with PostgreSQL. For
> example, making sure the users' currently slot is compatible with the
> ebuild requirements. postgres.eclass addresses this and has
> additional conveniences to build a dependency string and add a new user
> into the postgres system group.
> 
> Additionally, as most of you are aware, we have a slot capable
> dev-db/postgresql. There is some difficulty that needed to be resolved
> so that extensions could also be installed into multiple slots, which is
> addressed by postgres-multi.eclass.
> 
> I've an overlay at:
> https://github.com/titanofold/titanofold-gentoo-x86
> 
> With the pgsql-eclass branch containing the eclass and a postgres-multi
> enabled PostGIS.
> 
> Naturally, the eclasses work for me, so far.
> 
> For your convenience, I've also attached the eclasses.
> 

You might wanna add some quotes around the variables in that line:
enewuser $1 $2 $3 $4 ${groups}

Cheers,

Manuel


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 605 bytes --]

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

[Aaron W. Swenson]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

On 2016-01-12 21:57, Manuel Rüger wrote:
> On 12.01.2016 20:22, Aaron W. Swenson wrote:
> > There are several ebuilds that repeat the same checks and need to
> > perform the same duties when it comes to working with PostgreSQL. For
> > example, making sure the users' currently slot is compatible with the
> > ebuild requirements. postgres.eclass addresses this and has
> > additional conveniences to build a dependency string and add a new user
> > into the postgres system group.
> > 
> > Additionally, as most of you are aware, we have a slot capable
> > dev-db/postgresql. There is some difficulty that needed to be resolved
> > so that extensions could also be installed into multiple slots, which is
> > addressed by postgres-multi.eclass.
> > 
> > I've an overlay at:
> > https://github.com/titanofold/titanofold-gentoo-x86
> > 
> > With the pgsql-eclass branch containing the eclass and a postgres-multi
> > enabled PostGIS.
> > 
> > Naturally, the eclasses work for me, so far.
> > 
> > For your convenience, I've also attached the eclasses.
> > 
> 
> You might wanna add some quotes around the variables in that line:
> enewuser $1 $2 $3 $4 ${groups}
> 
> Cheers,
> 
> Manuel
> 

Done.

https://github.com/titanofold/titanofold-gentoo-x86/commit/976455582c95d62ed7ee5c102e58948a4afb037c

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 345 bytes --]

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

>> On 12.01.2016 20:22, Aaron W. Swenson wrote:
>>> There are several ebuilds that repeat the same checks and
>>> need to perform the same duties when it comes to working with
>>> PostgreSQL. For example, making sure the users' currently
>>> slot is compatible with the ebuild requirements.
>>> postgres.eclass addresses this and has additional
>>> conveniences to build a dependency string and add a new user 
>>> into the postgres system group.
>>> 
>>> Additionally, as most of you are aware, we have a slot
>>> capable dev-db/postgresql. There is some difficulty that
>>> needed to be resolved so that extensions could also be
>>> installed into multiple slots, which is addressed by
>>> postgres-multi.eclass.
>>> 
>>> I've an overlay at: 
>>> https://github.com/titanofold/titanofold-gentoo-x86
>>> 
>>> With the pgsql-eclass branch containing the eclass and a
>>> postgres-multi enabled PostGIS.
>>> 
>>> Naturally, the eclasses work for me, so far.
>>> 

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.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlaWdzAACgkQAJxUfCtlWe1k9gEAvZZ93mdUhDwTKBxcX+GcrZ5S
bwCQKIkuItSIz0221usA/1rnPt2dGWr9tGMqxekvNypx5RKnF3odSb0m1EVSnTJR
=2xB+
-----END PGP SIGNATURE-----

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

[Aaron W. Swenson]

[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 345 bytes --]

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

[Ian Stakenvicius]

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

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

[Ian Stakenvicius]

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

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

[Aaron W. Swenson]

[-- Attachment #1: Type: text/plain, Size: 3446 bytes --]

On 2016-01-15 12:43, Ian Stakenvicius wrote:
> -----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:
> 
> > POSTGRES_DEP+=" postgres_${slot}? ("
> > POSTGRES_DEP+=" dev-db/postgresql:${slot}=" 
> > declare -p POSTGRES_USEDEP &>/dev/null && \ 
> > POSTGRES_DEP+="[${POSTGRES_USEDEP}]" +		POSTGRES_DEP+=" )"


I only briefly looked at the Python eclasses and was having a bit of a
hard time following.

I see the conditional use now.

> The main issue I still saw though was this, in postgres-multi.eclass:
> 
> > # @FUNCTION: postgres-multi_pkg_setup
> >      ...
> 
> ..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.

Oh, yes, I'll change that, too. I was just focusing on the depend bit.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 345 bytes --]

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The eclasses look good to go for me -- i've built an ebuild for pl/R
using them and it works as expected (and it's nice to not have to
define PG_CONFIG et. al. myself too).

Can the eclasses be migrated to the tree soon?

Also of note, it will be important to stabilize soon the ~arch
versions of postgresql that have the install_bin path patched;
otherwise if portage is, say, reinstalled with a different python
selection between when postgres is emerged and one of these new
postgres-multi packages are emerged, installation fails.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlaiXiMACgkQAJxUfCtlWe0DUAD/Xj9R3KTYHUBMaXdLioxNtP+N
yzx0Fy3y+eGBpGj0i6wBAOqi/oeRWAOINcl+RNfval46qr2R7Wr9ago2V1eqT+R0
=t7kM
-----END PGP SIGNATURE-----

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

[Aaron W. Swenson]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

On 2016-01-22 11:51, Ian Stakenvicius wrote:
> The eclasses look good to go for me -- i've built an ebuild for pl/R
> using them and it works as expected (and it's nice to not have to
> define PG_CONFIG et. al. myself too).
> 
> Can the eclasses be migrated to the tree soon?

I wanted to test the eclass against pgTAP as well with the default
functions, but have been struggling the past couple days with getting my
machine up to date.

I would like some feedback on the documentation/comments in the
eclass. I'm certain it could be improved. Though, if you were able to
follow them (not a slight, just you were the first to follow them), I
might have done good enough.

> Also of note, it will be important to stabilize soon the ~arch
> versions of postgresql that have the install_bin path patched;
> otherwise if portage is, say, reinstalled with a different python
> selection between when postgres is emerged and one of these new
> postgres-multi packages are emerged, installation fails.

Oh, yes, I think we can move towards stabilization as soon as my
Internet is back up.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 345 bytes --]

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

[Ian Stakenvicius]

> On Jan 22, 2016, at 3:11 PM, Aaron W. Swenson <titanofold@gentoo.org> wrote:
> 
> 
> I would like some feedback on the documentation/comments in the
> eclass. I'm certain it could be improved. Though, if you were able to
> follow them (not a slight, just you were the first to follow them), I
> might have done good enough.
> 

I'll have another look; i don't think I read any of the docs, just looked to see that PG_CONFIG was set for me and confirmed things looked to work the same as multilib-minimal.

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

[Aaron W. Swenson]

[-- Attachment #1.1: Type: text/plain, Size: 125 bytes --]

Okay, provided that the new USE_EXPAND is okay for POSTGRES_TARGETS,
attached are the eclasses that I'll commit to the tree.

[-- Attachment #1.2: postgres-multi.eclass --]
[-- Type: text/plain, Size: 4468 bytes --]

# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

inherit multibuild postgres
EXPORT_FUNCTIONS pkg_setup src_prepare src_compile src_install src_test


# @ECLASS: postgres-multi
# @MAINTAINER:
# PostgreSQL <pgsql-bugs@gentoo.org>
# @AUTHOR: Aaron W. Swenson <titanofold@gentoo.org>
# @BLURB: An eclass to build PostgreSQL-related packages against multiple slots
# @DESCRIPTION:
# postgres-multi enables ebuilds, particularly PostgreSQL extensions, to
# build against any and all compatible PostgreSQL slots that are also
# enabled by the user. Additionally makes a developer's life easier with
# exported default functions to do the right thing.


case ${EAPI:-0} in
  0|1|2|3|4) die "postgres-multi.eclass requires EAPI 5 or higher" ;;
  *) ;;
esac


# @ECLASS-VARIABLE: POSTGRES_COMPAT
# @REQUIRED
# @DESCRIPTION:
# A Bash array containing a list of compatible PostgreSQL slots as
# defined by the developer. Must be declared before inheriting this eclass.
if ! declare -p POSTGRES_COMPAT &>/dev/null; then
	die 'Required variable POSTGRES_COMPAT not declared.'
fi

# @ECLASS-VARIABLE: _POSTGRES_UNION_SLOTS
# @INTERNAL
# @DESCRIPTION:
# A Bash array containing the union set of user-enabled slots that are
# also in POSTGRES_COMPAT.
export _POSTGRES_UNION_SLOTS=( )

# @FUNCTION _postgres-multi_multibuild_wrapper
# @INTERNAL
# @USAGE: _postgres-multi_multibuild_wrapper <command> [<arg> ...]
# @DESCRIPTION:
# For the given variant, set the values of the PG_SLOT and PG_CONFIG
# environment variables accordingly and replace any appearance of
# @PG_SLOT@ in the command and arguments with value of ${PG_SLOT}.
_postgres-multi_multibuild_wrapper() {
	debug-print-function ${FUNCNAME} "${@}"
	export PG_SLOT=${MULTIBUILD_VARIANT}
	export PG_CONFIG=$(which pg_config${MULTIBUILD_VARIANT//./})
	$(echo "${@}" | sed "s/@PG_SLOT@/${PG_SLOT}/g")
}

# @FUNCTION: postgres-multi_foreach
# @USAGE: postgres-multi_foreach <command> <arg> [<arg> ...]
# @DESCRIPTION:
# Run the given command in the package's source directory for each
# PostgreSQL slot in the union set of the developer defined
# POSTGRES_COMPAT and user-enabled slots. The PG_CONFIG environment
# variable is updated on each iteration to point to the matching
# pg_config command for the current slot. Any appearance of @PG_SLOT@ in
# the command or arguments will be substituted with the slot (e.g., 9.5)
# of the current iteration.
postgres-multi_foreach() {
	local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[@]}")

	multibuild_foreach_variant \
		_postgres-multi_multibuild_wrapper run_in_build_dir ${@}
}

# @FUNCTION: postgres-multi_forbest
# @USAGE: postgres-multi_forbest <command> <arg> [<arg> ...]
# @DESCRIPTION:
# Run the given command in the package's source directory for the best,
# compatible PostgreSQL slot. The PG_CONFIG environment variable is set
# to the matching pg_config command. Any appearance of @PG_SLOT@ in the
# command or arguments will be substituted with the matching slot (e.g., 9.5).
postgres-multi_forbest() {
	# POSTGRES_COMPAT is reverse sorted once in postgres.eclass so
	# element 0 has the highest slot version.
	local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[0]}")

	multibuild_foreach_variant \
		_postgres-multi_multibuild_wrapper run_in_build_dir ${@}
}

# @FUNCTION: postgres-multi_pkg_setup
# @USAGE: postgres-multi_pkg_setup
# @DESCRIPTION:
# Initialize internal environment variable(s). This is required if
# pkg_setup() is declared in the ebuild.
postgres-multi_pkg_setup() {
	local user_slot

	for user_slot in "${POSTGRES_COMPAT[@]}"; do
		use "postgres_targets_postgres${user_slot/\./_}" && \
			_POSTGRES_UNION_SLOTS+=( "${user_slot}" )
	done

	if [[ "${#_POSTGRES_UNION_SLOTS[@]}" -eq "0" ]]; then
		die "One of the postgres_targets_postgresSL_OT use flags must be enabled"
	fi

	elog "Multibuild variants: ${_POSTGRES_UNION_SLOTS[@]}"
}

postgres-multi_src_prepare() {
	if [[ "${#_POSTGRES_UNION_SLOTS[@]}" -eq "0" ]]; then
		eerror "Internal array _POSTGRES_UNION_SLOTS is empty."
		die "Did you forget to call postgres-multi_pkg_setup?"
	fi

	local MULTIBUILD_VARIANT
	local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[@]}")
	multibuild_copy_sources
}

postgres-multi_src_compile() {
	postgres-multi_foreach emake
}

postgres-multi_src_install() {
	postgres-multi_foreach emake install DESTDIR="${D}"
}

postgres-multi_src_test() {
	postgres-multi_foreach emake installcheck
}

[-- Attachment #1.3: postgres.eclass --]
[-- Type: text/plain, Size: 3829 bytes --]

# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

inherit user

# @ECLASS: postgres
# @MAINTAINER:
# PostgreSQL <pgsql-bugs@gentoo.org>
# @AUTHOR: Aaron W. Swenson <titanofold@gentoo.org>
# @BLURB: An eclass for PostgreSQL-related packages
# @DESCRIPTION:
# This eclass provides common utility functions that many
# PostgreSQL-related packages perform, such as checking that the
# currently selected PostgreSQL slot is within a range, adding a system
# user to the postgres system group, and generating dependencies.


case ${EAPI:-0} in
  0|1|2|3|4) die "postgres.eclass requires EAPI 5 or higher" ;;
  *) ;;
esac


# @ECLASS-VARIABLE: POSTGRES_COMPAT
# @DESCRIPTION:
# A Bash array containing a list of compatible PostgreSQL slots as
# defined by the developer. If declared, must be declared before
# inheriting this eclass. Example: POSTGRES_COMPAT=( 9.4 9.{5,6} )

# @ECLASS-VARIABLE: POSTGRES_USEDEP
# @DESCRIPTION:
# Add the, without brackets, 2-Style and/or 4-Style use dependencies to
# be used for POSTGRES_DEP. If declared, must be declared before
# inheriting this eclass.

# @ECLASS-VARIABLE: POSTGRES_DEP
# @DESCRIPTION:
# An automatically generated dependency string suitable for use in
# DEPEND and RDEPEND declarations.

# @ECLASS-VARIABLE: POSTGRES_REQ_USE
# @DESCRIPTION:
# An automatically generated REQUIRED_USE-compatible string built upon
# POSTGRES_COMPAT. REQUIRED_USE="... ${POSTGRES_REQ_USE}" is only
# required if the package must build against one of the PostgreSQL slots
# declared in POSTGRES_COMPAT.

if declare -p POSTGRES_COMPAT &> /dev/null ; then
	# Reverse sort the given POSTGRES_COMPAT so that the most recent
	# slot is preferred over an older slot.
	# -- do we care if dependencies are deterministic by USE flags?
	readarray -t POSTGRES_COMPAT < <(printf '%s\n' "${POSTGRES_COMPAT[@]}" | sort -nr)

	POSTGRES_DEP=""
	POSTGRES_REQ_USE=" || ("
	for slot in "${POSTGRES_COMPAT[@]}" ; do
		POSTGRES_DEP+=" postgres_targets_postgres${slot/\./_}? ( dev-db/postgresql:${slot}="
		declare -p POSTGRES_USEDEP &>/dev/null && \
			POSTGRES_DEP+="[${POSTGRES_USEDEP}]"
		POSTGRES_DEP+=" )"

		IUSE+=" postgres_targets_postgres${slot/\./_}"
		POSTGRES_REQ_USE+=" postgres_targets_postgres${slot/\./_}"
	done
	POSTGRES_REQ_USE+=" )"
else
	POSTGRES_DEP="dev-db/postgresql:="
	declare -p POSTGRES_USEDEP &>/dev/null && \
		POSTGRES_DEP+="[${POSTGRES_USEDEP}]"
fi


# @FUNCTION: postgres_check_slot
# @DESCRIPTION:
# Verify that the currently selected PostgreSQL slot is set to one of
# the slots defined in POSTGRES_COMPAT. Automatically dies unless a
# POSTGRES_COMPAT slot is selected. Should be called in pkg_pretend().
postgres_check_slot() {
	if ! declare -p POSTGRES_COMPAT &>/dev/null; then
		die 'POSTGRES_COMPAT not declared.'
	fi

	# Don't die because we can't run postgresql-config during pretend.
	[[ "$EBUILD_PHASE" = "pretend" && -z "$(which postgresql-config 2> /dev/null)" ]] \
		&& return 0

	if has $(postgresql-config show 2> /dev/null) "${POSTGRES_COMPAT[@]}"; then
		return 0
	else
		eerror "PostgreSQL slot must be set to one of: "
		eerror "    ${POSTGRES_COMPAT[@]}"
		die "Incompatible PostgreSQL slot eselected"
	fi
}

# @FUNCTION: postgres_new_user
# @DESCRIPTION:
# Creates the "postgres" system group and user -- which is separate from
# the database user -- in addition to the developer defined user. Takes
# the same arguments as "enewuser".
postgres_new_user() {
	enewgroup postgres 70
	enewuser postgres 70 /bin/bash /var/lib/postgresql postgres

	if [[ $# -gt 0 ]] ; then
		if [[ "$1" = "postgres" ]] ; then
			ewarn "Username 'postgres' implied, skipping"
		else
			local groups=$5
			[[ -n "${groups}" ]] && groups+=",postgres" || groups="postgres"
			enewuser "$1" "$2" "$3" "$4" "${groups}"
		fi
	fi
}

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 345 bytes --]

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

[Michael Orlitzky]

On 01/24/2016 06:29 PM, Aaron W. Swenson wrote:
> Okay, provided that the new USE_EXPAND is okay for POSTGRES_TARGETS,
> attached are the eclasses that I'll commit to the tree.
> 

> case ${EAPI:-0} in
>   0|1|2|3|4) die "postgres-multi.eclass requires EAPI 5 or higher" ;;
>   *) ;;
> esac

Does this really work with EAPI=6? I didn't try, but it looks like it
would need an eapply_user somewhere in src_prepare. And, pedantry
warning, there's no such thing as "EAPI 5 or higher." The lawyers will
tell you to do something like this instead (stolen from git-r3):

  case "${EAPI:-0}" in
	  5|6)
		  ;;
	  *)
		  die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
		  ;;
  esac

That will require an edit for every new EAPI, but prevents weird crashes
from things like a missing eapply_user.

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

[Aaron W. Swenson]

[-- Attachment #1.1: Type: text/plain, Size: 1070 bytes --]

On 2016-01-24 18:44, Michael Orlitzky wrote:
> On 01/24/2016 06:29 PM, Aaron W. Swenson wrote:
> > Okay, provided that the new USE_EXPAND is okay for POSTGRES_TARGETS,
> > attached are the eclasses that I'll commit to the tree.
> > 
> 
> > case ${EAPI:-0} in
> >   0|1|2|3|4) die "postgres-multi.eclass requires EAPI 5 or higher" ;;
> >   *) ;;
> > esac
> 
> Does this really work with EAPI=6? I didn't try, but it looks like it
> would need an eapply_user somewhere in src_prepare. And, pedantry
> warning, there's no such thing as "EAPI 5 or higher." The lawyers will
> tell you to do something like this instead (stolen from git-r3):
> 
>   case "${EAPI:-0}" in
> 	  5|6)
> 		  ;;
> 	  *)
> 		  die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
> 		  ;;
>   esac
> 
> That will require an edit for every new EAPI, but prevents weird crashes
> from things like a missing eapply_user.
> 
> 

Thank you.

I've added the eapply_user to postgres-multi and modified the case
condition to match the hot goods you're selling on the sly.

[-- Attachment #1.2: postgres-multi.eclass --]
[-- Type: text/plain, Size: 4482 bytes --]

# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

inherit multibuild postgres
EXPORT_FUNCTIONS pkg_setup src_prepare src_compile src_install src_test


# @ECLASS: postgres-multi
# @MAINTAINER:
# PostgreSQL <pgsql-bugs@gentoo.org>
# @AUTHOR: Aaron W. Swenson <titanofold@gentoo.org>
# @BLURB: An eclass to build PostgreSQL-related packages against multiple slots
# @DESCRIPTION:
# postgres-multi enables ebuilds, particularly PostgreSQL extensions, to
# build against any and all compatible PostgreSQL slots that are also
# enabled by the user. Additionally makes a developer's life easier with
# exported default functions to do the right thing.


case ${EAPI:-0} in
  0|1|2|3|4) die "postgres-multi.eclass requires EAPI 5 or higher" ;;
  *) ;;
esac


# @ECLASS-VARIABLE: POSTGRES_COMPAT
# @REQUIRED
# @DESCRIPTION:
# A Bash array containing a list of compatible PostgreSQL slots as
# defined by the developer. Must be declared before inheriting this eclass.
if ! declare -p POSTGRES_COMPAT &>/dev/null; then
	die 'Required variable POSTGRES_COMPAT not declared.'
fi

# @ECLASS-VARIABLE: _POSTGRES_UNION_SLOTS
# @INTERNAL
# @DESCRIPTION:
# A Bash array containing the union set of user-enabled slots that are
# also in POSTGRES_COMPAT.
export _POSTGRES_UNION_SLOTS=( )

# @FUNCTION _postgres-multi_multibuild_wrapper
# @INTERNAL
# @USAGE: _postgres-multi_multibuild_wrapper <command> [<arg> ...]
# @DESCRIPTION:
# For the given variant, set the values of the PG_SLOT and PG_CONFIG
# environment variables accordingly and replace any appearance of
# @PG_SLOT@ in the command and arguments with value of ${PG_SLOT}.
_postgres-multi_multibuild_wrapper() {
	debug-print-function ${FUNCNAME} "${@}"
	export PG_SLOT=${MULTIBUILD_VARIANT}
	export PG_CONFIG=$(which pg_config${MULTIBUILD_VARIANT//./})
	$(echo "${@}" | sed "s/@PG_SLOT@/${PG_SLOT}/g")
}

# @FUNCTION: postgres-multi_foreach
# @USAGE: postgres-multi_foreach <command> <arg> [<arg> ...]
# @DESCRIPTION:
# Run the given command in the package's source directory for each
# PostgreSQL slot in the union set of the developer defined
# POSTGRES_COMPAT and user-enabled slots. The PG_CONFIG environment
# variable is updated on each iteration to point to the matching
# pg_config command for the current slot. Any appearance of @PG_SLOT@ in
# the command or arguments will be substituted with the slot (e.g., 9.5)
# of the current iteration.
postgres-multi_foreach() {
	local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[@]}")

	multibuild_foreach_variant \
		_postgres-multi_multibuild_wrapper run_in_build_dir ${@}
}

# @FUNCTION: postgres-multi_forbest
# @USAGE: postgres-multi_forbest <command> <arg> [<arg> ...]
# @DESCRIPTION:
# Run the given command in the package's source directory for the best,
# compatible PostgreSQL slot. The PG_CONFIG environment variable is set
# to the matching pg_config command. Any appearance of @PG_SLOT@ in the
# command or arguments will be substituted with the matching slot (e.g., 9.5).
postgres-multi_forbest() {
	# POSTGRES_COMPAT is reverse sorted once in postgres.eclass so
	# element 0 has the highest slot version.
	local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[0]}")

	multibuild_foreach_variant \
		_postgres-multi_multibuild_wrapper run_in_build_dir ${@}
}

# @FUNCTION: postgres-multi_pkg_setup
# @USAGE: postgres-multi_pkg_setup
# @DESCRIPTION:
# Initialize internal environment variable(s). This is required if
# pkg_setup() is declared in the ebuild.
postgres-multi_pkg_setup() {
	local user_slot

	for user_slot in "${POSTGRES_COMPAT[@]}"; do
		use "postgres_targets_postgres${user_slot/\./_}" && \
			_POSTGRES_UNION_SLOTS+=( "${user_slot}" )
	done

	if [[ "${#_POSTGRES_UNION_SLOTS[@]}" -eq "0" ]]; then
		die "One of the postgres_targets_postgresSL_OT use flags must be enabled"
	fi

	elog "Multibuild variants: ${_POSTGRES_UNION_SLOTS[@]}"
}

postgres-multi_src_prepare() {
	if [[ "${#_POSTGRES_UNION_SLOTS[@]}" -eq "0" ]]; then
		eerror "Internal array _POSTGRES_UNION_SLOTS is empty."
		die "Did you forget to call postgres-multi_pkg_setup?"
	fi

	eapply_user

	local MULTIBUILD_VARIANT
	local MULTIBUILD_VARIANTS=("${_POSTGRES_UNION_SLOTS[@]}")
	multibuild_copy_sources
}

postgres-multi_src_compile() {
	postgres-multi_foreach emake
}

postgres-multi_src_install() {
	postgres-multi_foreach emake install DESTDIR="${D}"
}

postgres-multi_src_test() {
	postgres-multi_foreach emake installcheck
}

[-- Attachment #1.3: postgres.eclass --]
[-- Type: text/plain, Size: 3828 bytes --]

# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$

inherit user

# @ECLASS: postgres
# @MAINTAINER:
# PostgreSQL <pgsql-bugs@gentoo.org>
# @AUTHOR: Aaron W. Swenson <titanofold@gentoo.org>
# @BLURB: An eclass for PostgreSQL-related packages
# @DESCRIPTION:
# This eclass provides common utility functions that many
# PostgreSQL-related packages perform, such as checking that the
# currently selected PostgreSQL slot is within a range, adding a system
# user to the postgres system group, and generating dependencies.


case ${EAPI:-0} in
	5|6) ;;
	*) die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}" ;;
esac


# @ECLASS-VARIABLE: POSTGRES_COMPAT
# @DESCRIPTION:
# A Bash array containing a list of compatible PostgreSQL slots as
# defined by the developer. If declared, must be declared before
# inheriting this eclass. Example: POSTGRES_COMPAT=( 9.4 9.{5,6} )

# @ECLASS-VARIABLE: POSTGRES_USEDEP
# @DESCRIPTION:
# Add the, without brackets, 2-Style and/or 4-Style use dependencies to
# be used for POSTGRES_DEP. If declared, must be declared before
# inheriting this eclass.

# @ECLASS-VARIABLE: POSTGRES_DEP
# @DESCRIPTION:
# An automatically generated dependency string suitable for use in
# DEPEND and RDEPEND declarations.

# @ECLASS-VARIABLE: POSTGRES_REQ_USE
# @DESCRIPTION:
# An automatically generated REQUIRED_USE-compatible string built upon
# POSTGRES_COMPAT. REQUIRED_USE="... ${POSTGRES_REQ_USE}" is only
# required if the package must build against one of the PostgreSQL slots
# declared in POSTGRES_COMPAT.

if declare -p POSTGRES_COMPAT &> /dev/null ; then
	# Reverse sort the given POSTGRES_COMPAT so that the most recent
	# slot is preferred over an older slot.
	# -- do we care if dependencies are deterministic by USE flags?
	readarray -t POSTGRES_COMPAT < <(printf '%s\n' "${POSTGRES_COMPAT[@]}" | sort -nr)

	POSTGRES_DEP=""
	POSTGRES_REQ_USE=" || ("
	for slot in "${POSTGRES_COMPAT[@]}" ; do
		POSTGRES_DEP+=" postgres_targets_postgres${slot/\./_}? ( dev-db/postgresql:${slot}="
		declare -p POSTGRES_USEDEP &>/dev/null && \
			POSTGRES_DEP+="[${POSTGRES_USEDEP}]"
		POSTGRES_DEP+=" )"

		IUSE+=" postgres_targets_postgres${slot/\./_}"
		POSTGRES_REQ_USE+=" postgres_targets_postgres${slot/\./_}"
	done
	POSTGRES_REQ_USE+=" )"
else
	POSTGRES_DEP="dev-db/postgresql:="
	declare -p POSTGRES_USEDEP &>/dev/null && \
		POSTGRES_DEP+="[${POSTGRES_USEDEP}]"
fi


# @FUNCTION: postgres_check_slot
# @DESCRIPTION:
# Verify that the currently selected PostgreSQL slot is set to one of
# the slots defined in POSTGRES_COMPAT. Automatically dies unless a
# POSTGRES_COMPAT slot is selected. Should be called in pkg_pretend().
postgres_check_slot() {
	if ! declare -p POSTGRES_COMPAT &>/dev/null; then
		die 'POSTGRES_COMPAT not declared.'
	fi

	# Don't die because we can't run postgresql-config during pretend.
	[[ "$EBUILD_PHASE" = "pretend" && -z "$(which postgresql-config 2> /dev/null)" ]] \
		&& return 0

	if has $(postgresql-config show 2> /dev/null) "${POSTGRES_COMPAT[@]}"; then
		return 0
	else
		eerror "PostgreSQL slot must be set to one of: "
		eerror "    ${POSTGRES_COMPAT[@]}"
		die "Incompatible PostgreSQL slot eselected"
	fi
}

# @FUNCTION: postgres_new_user
# @DESCRIPTION:
# Creates the "postgres" system group and user -- which is separate from
# the database user -- in addition to the developer defined user. Takes
# the same arguments as "enewuser".
postgres_new_user() {
	enewgroup postgres 70
	enewuser postgres 70 /bin/bash /var/lib/postgresql postgres

	if [[ $# -gt 0 ]] ; then
		if [[ "$1" = "postgres" ]] ; then
			ewarn "Username 'postgres' implied, skipping"
		else
			local groups=$5
			[[ -n "${groups}" ]] && groups+=",postgres" || groups="postgres"
			enewuser "$1" "$2" "$3" "$4" "${groups}"
		fi
	fi
}

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 345 bytes --]

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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/01/16 10:51 AM, Ian Stakenvicius wrote:
> 
> 
>> On Jan 22, 2016, at 3:11 PM, Aaron W. Swenson
>> <titanofold@gentoo.org> wrote:
>> 
>> 
>> I would like some feedback on the documentation/comments in
>> the eclass. I'm certain it could be improved. Though, if you
>> were able to follow them (not a slight, just you were the first
>> to follow them), I might have done good enough.
>> 
> 
> I'll have another look; i don't think I read any of the docs,
> just looked to see that PG_CONFIG was set for me and confirmed
> things looked to work the same as multilib-minimal.

OK here's my full review (with docs and all):

postgres.eclass:

postgres_check_slot() <-- #1, not seeing a need for this as
dependencies should be forced now due to USE flag provisions.  #2,
though, the documentation says it should be used in pkg_pretend but
then in the code there's an exclusion to make it a no-op when it's
run in pkg_pretend.  Perhaps it's supposed to be run in pkg_setup??

postgres_new_user() <-- the documentation seems a little bit unclear
on this one..  It looks like it creates the 'postgres' user/group
and optionally it also creates an additional specified user/group..
 But i'm not sure how creating new users/groups here instead of with
calling enewuser/enewgroup directly in the ebuild is helpful per
se...?  It also seems a bit redundant if you wanted to create say, 2
or 3 extra users/groups, to repeatedly call enewuser postgres ....


postgres-multi.eclass:

#1 - main description could perhaps be changed from:

# build against any and all compatible PostgreSQL slots that are also
# enabled by the user.

to:

# build and install for one or more PostgreSQL slots as specified by
# POSTGRES_TARGETS use flags.

#2 - POSTGRES_COMPAT , needs an example and/or text to describe the
syntax of the slot specification.

#3 - _POSTGRES_UNION_SLOTS -- you actually mean here the
intersection between the two sets, rather than the union, right?
Var can likely stay as-is but the description should probably be
updated.

#4 - postgres-multi_foreach() -- this actually runs in the builddir,
not the source dir as mentioned in the text.

#5 - postgres-multi_forbest() -- maybe expand on what the "best"
slot is here, ie that it's the lexicographically biggest slot rather
than something else (like, say, the slot that's currently eselected)

#6 - need docs for postgres-multi_src_prepare() and so forth -- just
simple stuff will suffice I think:  postgres-multi_src_prepare()
copies ${S} into a build directory for each target PG_SLOT and
should be specified; the others are default functions that are
provided for convenience, but postgres-multi_foreach should be used
instead of these when customization is necessary.

...and I think that's it..

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlamP+kACgkQAJxUfCtlWe2wAAD/QlCKmkKl/9gr42ggY9RUpvUL
HLT1trvmzvto8QLXLeoBAOWRobPqIU4fcoI0on6CJdeVS+ZEK5MFcdf9qDn3yECA
=VjiJ
-----END PGP SIGNATURE-----

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

[Jonathan Callen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/25/2016 07:29 AM, Aaron W. Swenson wrote:
> On 2016-01-24 18:44, Michael Orlitzky wrote:
>> On 01/24/2016 06:29 PM, Aaron W. Swenson wrote:
>>> Okay, provided that the new USE_EXPAND is okay for
>>> POSTGRES_TARGETS, attached are the eclasses that I'll commit to
>>> the tree.
>>> 
>> 
>>> case ${EAPI:-0} in 0|1|2|3|4) die "postgres-multi.eclass
>>> requires EAPI 5 or higher" ;; *) ;; esac
>> 
>> Does this really work with EAPI=6? I didn't try, but it looks
>> like it would need an eapply_user somewhere in src_prepare. And,
>> pedantry warning, there's no such thing as "EAPI 5 or higher."
>> The lawyers will tell you to do something like this instead
>> (stolen from git-r3):
>> 
>> case "${EAPI:-0}" in 5|6) ;; *) die "Unsupported EAPI=${EAPI}
>> (unknown) for ${ECLASS}" ;; esac
>> 
>> That will require an edit for every new EAPI, but prevents weird
>> crashes from things like a missing eapply_user.
>> 
>> 
> 
> Thank you.
> 
> I've added the eapply_user to postgres-multi and modified the case 
> condition to match the hot goods you're selling on the sly.
> 

You missed the fix for EAPI in postgres-multi.eclass (it looks okay in
the other eclass, though).

- -- 
Jonathan Callen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWpukoAAoJEEIQbvYRB3mgD/8P/iCbnkSZGcwnbQ7EsV55apJ+
+AqzVJVbgvNkrK23JysYfDcT9Qthld5W1CX66YBg38PBJbDHrQPZQiAYypybVxo8
Liv8P2O4smBdYhIdFfcMw6ARyOpfRec1kiYiZr0YI/sM1pQF/UV2RuG+zJJILMwJ
f3gNoRN0u58hMX5F1LZn0vRcrp9FqovNy1MMQ83u1qZp6SwK81IZFmHXoyyEWmaO
zh1plMRfs9iD7DK6CzHBvRyIyShzJGcNLOkNM7qKU5GhAXi7bWuwx5ZZpD1peWLI
Rn9xXfffyA62eU7EGvUQG/PuAU1PErT9+nFhH6qqSBnOpcR3kFO8a5zgfLHogzJT
cDQf4XU9MxDCjvSF2c/2tnt1tXqBO7CTjvsaIgaok8vzLsmh6wwJCiqGb80gRWX7
4HIAKqH1QbBLfPkb54NQp8ixw1b+LmtcbgJQrpXpxJTrUqtnJKDaaXKblFO8eOW2
LeLYYxdzEz3rh6RiqT7NZ3iKKP6cFy7S4qlfe4qsXD7mns1eIqcx9Hdt8LuwDMnC
zGLb7TBThrhBTt1gRdsXNDZUhkO5YohNqIgeUO1+bEnWS2UGZNf4Mv69HZTgipLO
vZ2vPFevEW5zAqj8kXgZQjuyrq59TlCY9l2q/etf4oxk6e2Sge1TZ8dcfLA9kJ/E
SIdeJ4XRl36+p1ANzG6c
=F4Y9
-----END PGP SIGNATURE-----

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

[Aaron W. Swenson]

[-- Attachment #1: Type: text/plain, Size: 4148 bytes --]

On 2016-01-25 10:31, Ian Stakenvicius wrote:
> On 23/01/16 10:51 AM, Ian Stakenvicius wrote:
> >> On Jan 22, 2016, at 3:11 PM, Aaron W. Swenson
> >> <titanofold@gentoo.org> wrote:
> >> 
> >> I would like some feedback on the documentation/comments in
> >> the eclass. I'm certain it could be improved. Though, if you
> >> were able to follow them (not a slight, just you were the first
> >> to follow them), I might have done good enough.
> >> 
> > 
> > I'll have another look; i don't think I read any of the docs,
> > just looked to see that PG_CONFIG was set for me and confirmed
> > things looked to work the same as multilib-minimal.
> 
> OK here's my full review (with docs and all):
> 
> postgres.eclass:
> 
> postgres_check_slot() <-- #1, not seeing a need for this as
> dependencies should be forced now due to USE flag provisions.  #2,
> though, the documentation says it should be used in pkg_pretend but
> then in the code there's an exclusion to make it a no-op when it's
> run in pkg_pretend.  Perhaps it's supposed to be run in pkg_setup??

I'm a bit uncertain what to do with this. There are a few ebuilds that
check that the slot is set properly, and they do so as early as possible
so the user doesn't start the emerge and walk away thinking everything
will be okay. So, it tries to run the check, but won't die if the
PostgreSQL eselect module hasn't been emerged yet.

I could probably replace it with a pkg_setup that sets the PG_CONFIG
variable globally.

But, this would probably require another USE_EXPAND to do a single
target. I'm not against this, I just don't want to go use flag crazy.

> postgres_new_user() <-- the documentation seems a little bit unclear
> on this one..  It looks like it creates the 'postgres' user/group
> and optionally it also creates an additional specified user/group..
>  But i'm not sure how creating new users/groups here instead of with
> calling enewuser/enewgroup directly in the ebuild is helpful per
> se...?  It also seems a bit redundant if you wanted to create say, 2
> or 3 extra users/groups, to repeatedly call enewuser postgres ....

You're right about how it works. I could scratch the rest of the
function and have it just create the postgres system group and
user. It's intended to make it so that a developer doesn't have to look
up the postgres system user and group parameters in another ebuild, or
dig around for nonexistent documentation, which will be rectified but
that'll still be difficult to search.

> postgres-multi.eclass:
> 
> #1 - main description could perhaps be changed from:
> 
> # build against any and all compatible PostgreSQL slots that are also
> # enabled by the user.
> 
> to:
> 
> # build and install for one or more PostgreSQL slots as specified by
> # POSTGRES_TARGETS use flags.

Done.

> #2 - POSTGRES_COMPAT , needs an example and/or text to describe the
> syntax of the slot specification.

Done.

> #3 - _POSTGRES_UNION_SLOTS -- you actually mean here the
> intersection between the two sets, rather than the union, right?
> Var can likely stay as-is but the description should probably be
> updated.

Well, that's a bit embarrassing. You'd think I'd know the difference by
now. Renamed it _POSTGRES_INTERSECT_SLOTS and corrected other
appearances of union.

> #4 - postgres-multi_foreach() -- this actually runs in the builddir,
> not the source dir as mentioned in the text.

Done.

> #5 - postgres-multi_forbest() -- maybe expand on what the "best"
> slot is here, ie that it's the lexicographically biggest slot rather
> than something else (like, say, the slot that's currently eselected)

Done.

> #6 - need docs for postgres-multi_src_prepare() and so forth -- just
> simple stuff will suffice I think:  postgres-multi_src_prepare()
> copies ${S} into a build directory for each target PG_SLOT and
> should be specified; the others are default functions that are
> provided for convenience, but postgres-multi_foreach should be used
> instead of these when customization is necessary.

Done.

> ...and I think that's it..

Thanks!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 345 bytes --]

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

[Aaron W. Swenson]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

On 2016-01-25 22:34, Jonathan Callen wrote:
> On 01/25/2016 07:29 AM, Aaron W. Swenson wrote:
> > On 2016-01-24 18:44, Michael Orlitzky wrote:
> >> On 01/24/2016 06:29 PM, Aaron W. Swenson wrote:
> >>> Okay, provided that the new USE_EXPAND is okay for
> >>> POSTGRES_TARGETS, attached are the eclasses that I'll commit to
> >>> the tree.
> >>> 
> >> 
> >>> case ${EAPI:-0} in 0|1|2|3|4) die "postgres-multi.eclass
> >>> requires EAPI 5 or higher" ;; *) ;; esac
> >> 
> >> Does this really work with EAPI=6? I didn't try, but it looks
> >> like it would need an eapply_user somewhere in src_prepare. And,
> >> pedantry warning, there's no such thing as "EAPI 5 or higher."
> >> The lawyers will tell you to do something like this instead
> >> (stolen from git-r3):
> >> 
> >> case "${EAPI:-0}" in 5|6) ;; *) die "Unsupported EAPI=${EAPI}
> >> (unknown) for ${ECLASS}" ;; esac
> >> 
> >> That will require an edit for every new EAPI, but prevents weird
> >> crashes from things like a missing eapply_user.
> >> 
> >> 
> > 
> > Thank you.
> > 
> > I've added the eapply_user to postgres-multi and modified the case 
> > condition to match the hot goods you're selling on the sly.
> > 
> 
> You missed the fix for EAPI in postgres-multi.eclass (it looks okay in
> the other eclass, though).

Fixed. Thanks!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 345 bytes --]