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