| 1 |
On Fri, Feb 1, 2013 at 10:51 AM, Richard Yao <ryao@g.o> wrote: |
| 2 |
> I suspect that the removal message is inaccurate. The actual reason for |
| 3 |
> removal is the following: |
| 4 |
> |
| 5 |
> https://bugs.gentoo.org/show_bug.cgi?id=425298 |
| 6 |
> |
| 7 |
> If you were to make a webpage for it and host the tarball for people, it |
| 8 |
> should be possible to resolve that bug. That should be sufficient to |
| 9 |
> have the removal mask removed. |
| 10 |
|
| 11 |
Yes, after sending out my email I took a closer look and came to the |
| 12 |
same conclusion. |
| 13 |
|
| 14 |
I'm perfectly fine with masking/removing packages that do not have |
| 15 |
valid SRC_URIs, and if somebody wants to host the tarball somewhere |
| 16 |
and submit a patch to fix it we shouldn't have a problem with a dev |
| 17 |
committing that patch and prolonging the package a bit longer (though |
| 18 |
ideally a proxy maintainer would be helpful). |
| 19 |
|
| 20 |
Bottom line is that we shouldn't drop packages simply because they're |
| 21 |
unmaintained or lack an upstream. Missing SRC_URIs on unmaintained |
| 22 |
packages are fair game, however, as are other serious issues. I have |
| 23 |
no desire to make the mirror maintainers sort through log noise on |
| 24 |
something like this. |
| 25 |
|
| 26 |
For those who are doing the treecleaning, please do yourself a favor |
| 27 |
and point out the actual show-stoppers so that you don't have a war on |
| 28 |
your hand every time you mask something. :) |
| 29 |
|
| 30 |
Rich |
Archives