Deprecated packages on Hackage?
Hi all, Is there a way to list all the deprecated packages on hackage? For instance I found this: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/control-timeout-0... via a google search but its not listed on the main hackage packages page. However, there are other packages which are marked DEPRECATED in their description strings. 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) Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
On Tue, Jun 09, 2009 at 08:54:17AM +1000, Erik de Castro Lopo wrote:
Is there a way to list all the deprecated packages on hackage?
Not unless you have an account on that machine. They're hiding, because their maintainers wanted them withdrawn.
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)
The former exists, and is used by the following: http-shed -> httpd-shed ieee754-parser -> data-binary-ieee754 Thingie -> Hieroglyph
Ross Paterson wrote:
On Tue, Jun 09, 2009 at 08:54:17AM +1000, Erik de Castro Lopo wrote:
Is there a way to list all the deprecated packages on hackage?
Not unless you have an account on that machine. They're hiding, because their maintainers wanted them withdrawn.
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. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
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
participants (3)
-
Erik de Castro Lopo -
Ketil Malde -
Ross Paterson