'temporary' package

[Herbert Valerio Riedel]

On 2014-05-11 at 01:41:56 +0200, Bardur Arantsson wrote:

[...]

> As usual Debian has encountered and solved all these problems before.
> Sounds eminently sensible, so +1 to such a policy change.

There's IMHO an important difference between Hackage and how Debian
operates:

Debian repackages upstream packages into a unified package repository
and also takes care of applying add-on patches to fix bugs and/or
integrate better with other repackaged Debian packages in the current
Debian release. There is not much need for the upstream maintainer to
cooperate.

Hackage, on the other hand, is both, a package repository *and* a place
where upstream authors publish their packages[1]. So on Hackage there
needs to active cooperation between package authors and Hackage
maintainers. For instance, package authors may not be bothered into
supporting 3-year old GHC setups which, OTOH, Hackage
trustee/maintainers might be willing to put in effort for, but there
still needs to be an agreement where the Hackage trustee authority ends,
and how absolute the package's authors wishes are in the context of some
form of Utilitaranism maximizing the total benefit for everyone using
Hackage.



 [1]: IMHO, publishing a package on Hackage also comes with a reasonable
      level of responsibility for package authors, as Hackage should be
      about keeping packages in a working state. It'd be a pity for
      Hackage to degenerate into a pastebin-like dumping space for
      bitrotting code where you have filter out all the noise to find
      out which packages are still maintained and working. 

      (Maybe the HP as the authority to pick go-to implementations may
      help here in the future, but I'm afraid we still have too many
      places with competing designs (with different trade-offs) for the
      same task, and I see the HP library addition process being blocked
      by that for the next few years -- but that's a worth a whole
      thread/discussion of its own)