'temporary' package

[John Meacham]

On Sat, May 10, 2014 at 4:30 AM, Alexander Berntsen
<alexander at plaimi.net> wrote:
> I just wanted to say that this whole thread is close to scaring me off
> *ever* putting a library on Hackage. I have worked in free software
> for quite some time, and let me assure you that it's not common
> practice elsewhere to hijack software if the maintainer does not
> respond for four days.

I strongly agree, which is why I almost never put anything on hackage, it's
a pretty fundamentally broken model. If your configuration manager can be
broken by an external dependency in a way that cannot be locally resolved,
then your configuration manager is not doing its job. Depending on hackage
packages is the number one reason for haskell code breakage and code-rot.

I pull out code I wrote myself just 3 years ago and find it can't build on a
sligthly newer version of the same compiler, yet C code, written to a 20
year old version of the language on a different OS with a different compiler
still adapts and works out of the box. We have somehow made a more messed up
dependency situation than C has.

Putting something on hackage means getting on the upgrade treadmill, I had
utterly portable pure haskell 98 libraries, people kept trying to "maintain"
them out from under me to being non-portable, meaning I have to actively
maintain it because it is no longer written to a standard or give up on the
hackage version which leads to confusion. I want to write code, not twiddle
dependencies for versions of ghc I don't even use.

It is telling that the best way to port cabal/ghc libraries to jhc is just
delete the cabal file and compile it anyway, despite the cabal file claiming
it depends on all sort of specific versions of things. _almost every broken
build is due to cabal having incorrect info and the package works perfectly
as is_, as in, cabal is actively making code _less_ portable. And, I can't
rightly blame the author, they had to put some arbitrary max version, and
hardcode some package names that are ghc specific, and they probably never
even heard of the compiler i'm trying to use. But none of these should be
issues for a real configuration manager it is exactly its job to _make
things like that work_.

Sigh. I have ranted this rant before. It is a real turn off to see how much
cabal build issues eat away at the general Haskell language list traffic. It
depresses me and I go away for a while. When you make a system requiring
work proportional to the square of code on hackage rather than linearly then
eventually all Haskell hacker brain cycles will be subsumed by hackage
library maintenance.

    John