Lately there's been a fair amount of discussion
about the growth of the NetBSD package collection.

Just thinking out loud- would it make sense to 
have a process in place to remove or reclassify broken
packages from the collection?  I.e.  to "deprecate" packages
or move them into a "no longer works & no one cares" category?

With all the emphasis on growth, it seems to me
that we can accumulate packages that with gradual
changes to the package collection, will no longer
compile, nor find enough takers to get them working
again.  Would it make sense to have a now-non-working
package put in some kind of "deprecated" category, 
so that people can browse through the package collection
and see that a package was compiled and run back in 
NetBSD-1.3/amana-microwave, but has never been
gotten to run since then?  

This way, if I desperately needed XFooBlozWoggit-1.0.3 
on NetBSD-1.4.1/braun-shaver, I (as the end user) could see
that yes, the package is available, but that I almost surely
will need to tinker with it to get it working on my 
current NetBSD host and OS version...?

Yes, that's additional work (having a "non-working"
package list?), but the nice thing about it, is that
just about no other free Unix-like OS's (except maybe
Debian Linux) will actually _tell_ you that a package
really doesn't work anymore.  Instead, you have to find out
the hard way.  So if NetBSD could do this, this is 
something we could point to & say "This is an example
of our quality control in action."  NetBSD already does
something like this on other fronts, by making the -stable vs -current
distinction, and by having some ports marked as "experimental"
and others as "standard distribution."

Now, you might think, well, if a package is broken, then
The Right Thing to do is fix it.  ---Sure, if there is someone around
with know-how and time and interest to fix it.  It would still
be good (I think) to keep code available, even when there is no
current maintainer for it, in case a new maintainer comes along.
Maybe I need XFooBlozWoggit badly enough, that I'll fix it to 
run with the current set of libraries.

Anyway, just thinking out loud.  What do you all think?  Would it 
be practical to distinguish working packages from "orphaned" ones?

-lou