From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id C57221388BF for ; Fri, 15 Jan 2016 18:26:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4E79521C024; Fri, 15 Jan 2016 18:26:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4845C21C00E for ; Fri, 15 Jan 2016 18:26:46 +0000 (UTC) Received: from [192.168.1.130] (CPE002401f30b73-CM78cd8ec1b205.cpe.net.cable.rogers.com [99.224.138.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id 2EA183409A6 for ; Fri, 15 Jan 2016 18:26:45 +0000 (UTC) Subject: Re: [gentoo-dev] New Eclasses: postgres and postgres-multi References: <20160112192204.GB2008@gengoff.gsmr1.local> <569568CE.6040404@gentoo.org> <20160112215328.GC2008@gengoff.gsmr1.local> <56967730.8020702@gentoo.org> <20160115164308.GA1984@gengoff.gsmr1.local> <56992FD6.9000806@gentoo.org> To: gentoo-dev@lists.gentoo.org From: Ian Stakenvicius Message-ID: <569939E2.5070508@gentoo.org> Date: Fri, 15 Jan 2016 13:26:42 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <56992FD6.9000806@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: e6f0919f-638f-455e-8dc8-5348cab051db X-Archives-Hash: 7eca8d5a43a8e37b0d860b8897741f21 -----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-----