objection to removal of py-wxWidgets and wxGKT28

[Greg Troxel <gdt%lexort.com@localhost>]

(For various personal reasons I have not really been fully able to pay
attention recently, and this is one such area.)

I am objecting to the removal of py-wxWidgets and wxGTK28.  I realize
they are out of date and and out of date version.  However, the
fundamental question about removals is the continued pain that the
continued presence of these cause, compared to the benefit to users.  In
many cases, users actually use code that is no longer maintained
upstream.

As part of what feels like overly aggressive deletions, a lot of
packages with dead upstreams have been removed.  In my view a dead
upstream for 5 years (less than 5 is not really really dead) is a strong
clue that the package is not useful.  However, that needs to be combined
with either a belief that there aren't users or that the continued
presence is causing problems.

Being blocked from removing wxGTK28 is not a problem, unless the
presence of wxGTK28 is an actual problem, rather than a cleanliness
issue.

Therefore I see "remove X because it depends on Y and we want to remove
Y" as not legitimate.  X should be removed if it should be removed on
its own merits.  And if we are going to remove Y, then the question is
the maintenance pain of Y's continued existence, compared to total
usefulness of everything that is removed.

And, I know wip technically doesn't count, but things in wip that are
nearly ready for import should be viewed as part of pkgsrc, when
considering the cost of "rm -rf Y".

I will go back and try to read the discussion, but I do not remember
seeing anything that argued that the continued presence of wxGTK28 and
py-wxWidgets (before an overdue update) is causing real trouble.

I do intend to look at updating py-wxWidgets, because wip/chirp (which
is just about due for hoisting to ham/chirp, and is maintained upstream)
uses it, but the time frame from the discussion starting to removals has
been too short to cope with that.