# Upstream is dead and gone.
# Masked for removal on 20130302
Erm, so this is the _only_ reason - dead upstream?
++
Please, please, stop removing packages for no reason!
This happens now way too often:
app-dicts/ispell*
app-portage/epm
app-text/ispell
games-arcade/bitefusion
games-arcade/xboing
games-action/trackballs
games-emulation/xmame
...
These are just some of the previous examples which I remember
because I had to put them in my local overlay.
None of these removals alone was so valuable to me that I saw
a reason to step up, but the removals for no reasons accumulate
previously so much that I see the need to say something:
You are destroying the charme of gentoo by systematically
removing all these little tools and toys. The availability
of a lot of software was once a strength of gentoo, so removing
these things is really bad, especially if it happens for no
real reason.
I was understanding if e.g. someting was removed which needs
the <gtk-2 or <qt-4 framework or something similar and had
a dead upstream. But just needing a small tool like imake (xboing)
or having open feature requestes (epm) or even nothing and
just dead upstream is IMHO really not a reason.
If something really does not compile anymore and nobody cares,
then remove keywords (or, for god's sake, mask it);
if something might theoretically become a security issue (xpdf)
then it should be masked.
But please do not throw things out of the tree unless
really necessary:
It does not hurt anybody to have such package in the tree,
but removing it - especially if upstream is dead - means
that the tarbalös will be removed from the mirrors and thus
nobody is able anymore to install it (even if he would care and
fix some minor issues) unless he had kept a copy on
his local machine (which will mean in the future that he can only
do it if he had used gentoo already many years ago and cared
during the time of the removal).
(If the resources are an argument: I am not speaking about monster
packages taking gigabytes of data - these might need to be
discussed separately - but mainly about reasonably sized packages
which even if summed up do not take much data).
Regards
Martin
