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