Erik de Castro Lopo
Finally, if a package is deprecated it might be usefult to have a reason as well so the hackage entry might say:
Deprecated : true (replaced by package XXX)
or
Deprecated : true (needs maintainer)
Or just Deprecated: (reason)?. Couldn't the presence of a Deprecated field be sufficient - the "true" seems gratuitious to me. One could also have something like Superseeds and Superseeded-by, of course, if that turns out to be the usual reasons for deprecation. And in a later post:
Well there is at least one package (network-dns) where the maintainter doesn't want to maintain it any more but would be happy for someone else to take it over.
It would be nice if something like this could be represented in the package metadata.
Absence of a "Maintainer" field? One problem is that the last uploaded package is likely to have an active maintainer, and when the maintainer disappears, he or she is unlikely to do a last update changing the status. Perhaps we could have automated emails to maintainers twice a year or so? -k -- If I haven't seen further, it is by standing in the footprints of giants