On 12/18/2012 12:26 AM, Duncan wrote: > Zac Medico posted on Mon, 17 Dec 2012 23:31:24 -0800 as excerpted: > >> On 12/17/2012 09:59 PM, Duncan wrote: > >>> [1] I long ago filed a bug suggesting a new world-sets line for >>> depclean, >>> but I expect it'll be resolved/fixed about the time sets support >>> finally gets unmasked to ~arch, the status of which looks about like >>> the tree's git conversion status... in practice, target "bluesky". I >>> guess these are gentoo's Duke Nukem' Forever projects. >> >> Fixed now: >> >> https://bugs.gentoo.org/show_bug.cgi?id=298298 >> >> It was a lot easier than the git conversion. ;-p > > Hurray! =:^) > > FWIW, I guess I wasn't as clear in my post as I was in my head, but what > I /intended/ to compare to the git conversion was sets support in at > least ~arch-unmasked portage. I've been eagerly awaiting both the git > tree conversion and sets support that ordinary users (at least in ~arch) > can use without unmasking, but both are complicated as much by the > political issues as the technical ones, so it's not as simple as just > hammering down on the technical issues and getting it done; the political > issues simply take /time/.
I guess you're talking about extended set configuration via /etc/portage/sets, /usr/share/portage/config/sets/, and $PORTDIR_OVERLAY/sets.conf? It's important to clarify that, because /etc/portage/sets (aka GLEP 21 User Sets) has already been supported in stable portage since 2.1.11.9 [1]. > This particular bug was taking some time too, but I wasn't worried about > it since I knew I was using a masked portage and it was n/a everywhere > else. I figured it'd be fixed eventually, as I said, about the time sets > support got unmasked to ~arch. > > But with luck, that's about to happen too, and I was right. Should I be > on the lookout for flying pigs too? =:^) > > Seriously, from your perspective, what /is/ the status on ~arch sets > support? I know I've not had any technical issues in that regard in > /ages/, but I believe the original political problem was that portage's > implementation of sets differed from that of paludis, and the idea was to > standardize on something that could be used by both, possibly covered by > PMS, so sets could be distributed in the tree, etc. And not being on the > PMS list and not having seen anything on it here, I'm not sure if there > has been any movement at all in that regard or not. And if not, is it > even practical to thing it could still happen? And if standardization > isn't practical, will the feature eventually be introduced, or dropped, > and if the plan is still to introduce it, is it something you believe you > can do right away as a portage update, or do you believe you need council > blessing for it, or? Before we had EAPI 5 sub-slots and slot-operators [1], there was a real danger of people over-using sets to trigger rebuilds, rather than doing it properly with sub-slots and slot-operators. Now that sub-slot and slot-operator support has been deployed in EAPI 5, it will be much easier to deter people from misusing sets like that. Therefore, it's now safer to consider enabling extended set configuration in stable portage. However, I'm not sure how useful extended set configuration really is. Maybe /etc/portage/sets is all that people really want/need. > I guess if you're bothering to commit depclean summary changes to support > sets, as you just did, the feature isn't on the cutting block yet, which > is a good sign, but I'd still like to be able to share sets with people > without worrying about explaining the concept and that support for it is > available but is still masked, every time. Is that something that I can > realistically expect to be able to do by say, the end of 2013, or not? As mentioned, /etc/portage/sets is supported in stable portage [1], so the depclean summary fix applies to stable portage. So, it doesn't necessarily imply that extended set configuration is not on the cutting block. [1] https://bugs.gentoo.org/show_bug.cgi?id=6411 [2] http://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators -- Thanks, Zac
