Hi,I was just looking at the reason why hgettext is marked for removal from testing. While doing so, I noticed that the last releases of the package have all been bumps to the dependencies. The last upstream release is from 2017, so apparently it is time to consider the package unmaintained upstream.
I think the original reason hgettext was packaged, was because I cared about it. This has changed, I don't use the package anymore and don't see a reason to have it in Debian. So from my perspective the package can be removed from the archive.
While checking the package-plan to see if hgettext can be safely removed, I noticed that it outputs 129 packages which aren't key packages or needed by key packages, i.e. candidates for removal from the archive. See below for the whole list.
Since I haven't been active in the Haskell Team for a long time, I'm not sure what the current practice is. But when I was still around, we tried to keep the set of packages small, by removing packages that nobody cares about (as identified by the “key” mark in the package-plan).
I don't want to suddenly start removing packages from under peoples noses. So maybe someone can clarify: Do we, as a team, still try to remove non-key packages or has the consensus shifted to just maintaining everything forever? If the former, maybe people should take a look at the packages in question, decide if they still want them in Debian and mark them as key packages (preferably with a comment explaining who to poke when the package breaks). Then we could set a deadline at which the remaining packages can be removed.
There are some packages in the list, which should probably not be removed. For example I think cabal-install should stay in Debian, even though I don't personally care about it. Some other packages look like there might be actual users who care about them (such as propellor, xmobar, xmonad-wallpaper). So maybe they should stay too? I'm not sure how aggressively we should be when removing packages. On one hand, I don't want to remove packages that people actually want to use, on the other hand I think we need to have some reliable way to keep our set of packages free from cruft that nobody cares about. Maybe someone else has some thoughts?
TL;DR * Do you care about hgettext or can it be removed from the archive?* Do you care about any of the other packages listed below or can they be removed from the archive? * Do you think we should be more active in monitoring Haskell packages for unneeded packages nobody cares about? How should we do so?
Regards Sven The list of packages reported by the package-plan is: BNFC BlogLiterately Chart-cairo DRBG GraphSCC HaskellForMaths HsOpenSSL-x509-system PSQueue ReadArgs Unixutils aeson-extra argon2 bool-extras boomerang bytestring-handle bzlib cabal-install cgi cipher-aes128 config-schema config-value control-monad-loop cryptohash-conduit cryptol curry-base curry-frontend data-default-instances-base debug-me descriptive diagrams-cairo diagrams-gtk dice-entropy-conduit djinn-ghc djinn-lib failure fclabels file-location finite-field generic-trie ghc-mtl gi-vte glirc gsasl gtk-traymanager happstack-authenticate happstack-jmacro haskell-qrencode hcwiid heist hgettext hierarchical-clustering hookup hsx-jmacro hxt-relaxng idna irc-core iwlib ixset jmacro libxml-sax lucid-svg map-syntax memoize mime monad-chronicle monadLib monadcryptorandom monadlist mtlparse multipart multiset-comb numtype only pandoc-citeproc-preamble pandoc-sidenote panic parallel-tree-search patat patience pcap posix-pty prelude-extras presburger propellor publicsuffixlist punycode pwstore-fast raaz readline regexpr repa sbv secret-sharing set-extra simple simple-smt smtLib smtp-mail snap snap-templates spool store store-core stringprep syb-with-class tagstream-conduit taskell template termonad test-framework-th-prime text-format th-utilities token-bucket tree-monad twitter-conduit twitter-types twitter-types-lens tz uri userid web-routes-boomerang xmlhtml xmobar xmonad-wallpaper yesod-auth-oauth yesod-default yi-frontend-pango zxcvbn-c
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature