| 1 |
On 2016-01-15 12:43, Ian Stakenvicius wrote: |
| 2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
| 3 |
> Hash: SHA256 |
| 4 |
> |
| 5 |
> On 15/01/16 11:43 AM, Aaron W. Swenson wrote: |
| 6 |
> > On 2016-01-13 11:11, Ian Stakenvicius wrote: |
| 7 |
> >> The work looks really good, but I noticed that postgres-multi |
| 8 |
> >> determins the variants to build against based on what's |
| 9 |
> >> installed on disk via checking eselect.. I think it'd likely |
| 10 |
> >> be better to instead have proper dependencies based on USE, |
| 11 |
> >> much like how the python and ABI_* multibuilds work. That |
| 12 |
> >> would make the installations as well as the dependencies be |
| 13 |
> >> determinstic rather than dynamic, which should support binpkgs |
| 14 |
> >> -much- better (among other things). |
| 15 |
> >> |
| 16 |
> >> The "|| ( postgresql:${SLOT1}= postgresql:${SLOT2}= ...)" |
| 17 |
> >> RDEPEND that postgres.eclass works out is a little sketchy |
| 18 |
> >> IMO, unfortunately, as the behaviour that occurs when more than |
| 19 |
> >> one of those slots are installed is afaik a little unstable -- |
| 20 |
> >> in theory, changes (including removal) of any of the options |
| 21 |
> >> should trigger a rebuild but I don't know if it does, and I'm |
| 22 |
> >> fairly certain that a simple --unmerge doesn't trigger a |
| 23 |
> >> rebuild. All of that goes away if you perform non-OR |
| 24 |
> >> dependency via use flags. |
| 25 |
> >> |
| 26 |
> >> The drawback of course is yet another USE_EXPAND, or at least |
| 27 |
> >> a bunch of rather long use flags, that will need setting by the |
| 28 |
> >> user. |
| 29 |
> > |
| 30 |
> > What if I made a small adjustment to the DEPEND building like |
| 31 |
> > so: |
| 32 |
> > |
| 33 |
> > - POSTGRES_DEP="|| (" + POSTGRES_REQ_USE=" || (" for slot in |
| 34 |
> > "${POSTGRES_COMPAT[@]}" ; do + IUSE+=" postgres_${slot}" + |
| 35 |
> > POSTGRES_REQ_USE+=" postgres_${slot}" + + ! use |
| 36 |
> > "postgres_${slot/_/.}" && continue POSTGRES_DEP+=" |
| 37 |
> > dev-db/postgresql:${slot}=" declare -p POSTGRES_USEDEP |
| 38 |
> > &>/dev/null && \ POSTGRES_DEP+="[${POSTGRES_USEDEP}]" done - |
| 39 |
> > POSTGRES_DEP+=" )" + POSTGRES_REQ_USE=" )" |
| 40 |
> > |
| 41 |
> > I'll have to change from listing the slots in POSTGRES_COMPAT |
| 42 |
> > from N.N to N_N, but that's not terribly difficult given the one |
| 43 |
> > ebuild I have it in. |
| 44 |
> > |
| 45 |
> > Is this a change that would require a USE_EXPAND? I know I'll |
| 46 |
> > have to document the USE flags globally. |
| 47 |
> > |
| 48 |
> |
| 49 |
> |
| 50 |
> A USE_EXPAND isn't necessary, all that provides is a way to group a |
| 51 |
> set of use flags with a prefix and hide the prefix from end-users |
| 52 |
> for cosmetic purposes. |
| 53 |
> |
| 54 |
> As for the patch, you can't determine RDEPEND (ie POSTGRES_DEP) |
| 55 |
> dynamically like that based on what use flags are being set, in |
| 56 |
> global scope -- its a runtime vs metadata-generation-time issue. |
| 57 |
> Changing it to this would work though: |
| 58 |
> |
| 59 |
> > POSTGRES_DEP+=" postgres_${slot}? (" |
| 60 |
> > POSTGRES_DEP+=" dev-db/postgresql:${slot}=" |
| 61 |
> > declare -p POSTGRES_USEDEP &>/dev/null && \ |
| 62 |
> > POSTGRES_DEP+="[${POSTGRES_USEDEP}]" + POSTGRES_DEP+=" )" |
| 63 |
|
| 64 |
|
| 65 |
I only briefly looked at the Python eclasses and was having a bit of a |
| 66 |
hard time following. |
| 67 |
|
| 68 |
I see the conditional use now. |
| 69 |
|
| 70 |
> The main issue I still saw though was this, in postgres-multi.eclass: |
| 71 |
> |
| 72 |
> > # @FUNCTION: postgres-multi_pkg_setup |
| 73 |
> > ... |
| 74 |
> |
| 75 |
> ..which, if i'm interpreting correctly, is what causes the postgres |
| 76 |
> extension to only be installed against what's on disk. Likely that |
| 77 |
> should be changed to build the list off of whatever postgres_[SLOT] |
| 78 |
> use flags are enabled. |
| 79 |
|
| 80 |
Oh, yes, I'll change that, too. I was just focusing on the depend bit. |
Archives