| 1 |
On Sun, 2 Mar 2014 19:58:47 +0100 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> > Honestly, setting up a tracker and blocking it with bugs about |
| 5 |
> > packages which someones-sub-SLOT-checking-script has vetted to be |
| 6 |
> > involved could be done in less than a day (for the hundred or so |
| 7 |
> > packages that depend on dev-libs/libgcrypt). It doesn't need some |
| 8 |
> > QA team to study in depth -- it needs a couple of volunteers to do |
| 9 |
> > the checks and file the bug reports. |
| 10 |
> |
| 11 |
> I'm not talking about libgcrypt. Those dependencies were 'mostly |
| 12 |
> fixed' already and no sane person will revbump every single package |
| 13 |
> just to make sure that everything will go right. Especially when |
| 14 |
> Council banned a few EAPIs and the revbump would have to be connected |
| 15 |
> with EAPI bump... and that would really make it all so happy and |
| 16 |
> awesome. |
| 17 |
|
| 18 |
The point would be to add the sub-SLOT token to *DEPEND at a revision |
| 19 |
bump or version bump. With a blocking bug for each affected package, |
| 20 |
and assuming maintainers check for open bug reports when they bump (as |
| 21 |
they already should), you would effectively make sure they *should* have |
| 22 |
known about adding the sub-SLOT changes. |
| 23 |
|
| 24 |
With only some helpful messages and friendly reminders on a general |
| 25 |
mailing list, you don't achieve the same effect. So again, if you or |
| 26 |
anyone else plans on giving a new library the same treatment, then get |
| 27 |
some people involved in filing the bug reports, so they get fixed within |
| 28 |
a good timeframe. We're still talking weeks to months to years for some |
| 29 |
libraries and their reverse dependencies, but at least we'd be on our |
| 30 |
way. |
| 31 |
|
| 32 |
|
| 33 |
jer |
Archives