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.
signature.asc
Description: Digital signature
