On Sun, Mar 2, 2014 at 2:44 PM, Mike Gilbert <[email protected]> wrote: > On Sun, Mar 2, 2014 at 1:09 PM, Jeroen Roovers <[email protected]> wrote: >> Honestly, setting up a tracker and blocking it with bugs about packages >> which someones-sub-SLOT-checking-script has vetted to be involved could >> be done in less than a day (for the hundred or so packages that depend >> on dev-libs/libgcrypt). It doesn't need some QA team to study in depth >> -- it needs a couple of volunteers to do the checks and file the bug >> reports. >> > > Unless I have missed mgorny's point here, this isn't just about > libraries that have currently subslots. This is about every single > library in the tree.
Correct - my script will spot packages that depend on libraries that are set up with subslots, but which don't contain a slot operator dep. It will not spot libraries that do not use subslots. However, I'm not sure why you'd need a tracker per library for that. Adding a subslot to a library impacts only that library. Once that is done then the script I wrote will detect all the other packages which should be modified to go along with it. You can add a subslot to a library without adding a corresponding slot operator dep to every package that uses it. I think it makes more sense to add subslots to libs and not revbump them, vs not doing anything for 18 months because it is too much work. Sure, the full benefit won't come up-front without all the work, but you'll at least get some benefit vs not ever getting any. The perfect is the enemy of the good... Rich
