On sob, 2017-06-03 at 13:00 +0200, Alexis Ballier wrote: > This whole thing definitely needs more thought and feedback but for now > those extra restrictions seem quite natural to me, allow easy solving > on the PM side and allow to have useful feedback from repoman. >
Well, I'll try to figure out the magic you were telling me later but as a quick note, my specific use case for this are Python targets, so I'm going throw a few basic concepts that need to work for you to play with ;-). In the following samples pt1,2,.. stands for PYTHON_TARGETS; pst1,2,... for PYTHON_SINGLE_TARGET. Eventually I'd like to kill the latter but that depends on how well the autosolving works. 1. ^^ ( pst1 pst2 pst3.. ) pst1? ( pt1 ) pst2? ( pt2 ) pst3? ( pt3 ).. This is the standard constraint for PYTHON_SINGLE_TARGET -- it needs to ensure that exactly one PYTHON_SINGLE_TARGET is selected, and that the matching PYTHON_TARGETS value is (other PYTHON_TARGETS can be enabled or disabled -- doesn't matter). 2. ^^ ( pst1 pst2.. ) pst1? ( pt1 ) pst2? ( pt2 ).. ^^ ( pt1 pt2 ) This is a possible extension of the above for the migration period. The idea is that exactly one PST must be selected, and only the matching PT must be selected (others are implicitly disabled). 3. doc? ( || ( pt3 pt4 ) ) || ( pt1 pt2 pt3 pt4 ) This is distutils-r1 with USE=doc requiring python2. Note that it's an example where the second || is added via eclass [NB: we've checked and PMS says eclass values are appended to ebuild value]. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
