サードパーティのパッケージに依存するHackageのパッケージがありますが、これは新しいバージョンのGHC（> = 7.2）では構築されません。LANGUAGE他のパッケージの問題は、1行のパッチ（プラグマ）だけで解決できます。パッチをアップストリームに2回送信しましたが、フィードバックがありませんでした。問題は、依存関係が修正されるまで、私のパッケージもインストールできないことです。
依存パッケージの修正バージョン（マイナーバージョンバンプ付き）をアップロードすることもできましたが、そのような非メンテナのアップロードに対するコミュニティの態度を聞きたいと思います。繰り返しになりますが、ライブラリインターフェイスを変更したくはありません。新しいコンパイルフラグを追加するだけで、再度ビルドできるようになります。
非メンテナによるパッケージのアップロードは許可されています（ライセンスの問題があるかもしれませんが、ハッキングのすべてではないにしてもほとんどのパッケージにはこれを許可するライセンスがあります）が、もちろん通常は行われません。誠意を持って合理的な手順で行われた場合、それらは許容されます。メンテナに連絡してn週間以内に応答がない場合（nの適切な値が3以上かどうかわからない場合）、新しいバージョンを自分でアップロードするオプションになります。しかし、メーリングリストでそれについて議論することはより賢明なようです。パッケージが放棄されたように見える場合は、メンテナシップを引き継ぐことでさえ（もちろん、メンテナに再度連絡した後、応答する時間を与える）が適切なアクションかもしれませんが、それは間違いなくコミュニティ（haskell-cafeまたはたとえば、メーリングリスト）。
しかし、どのパッケージが関係しているかを知っていて、具体的な状況を見ることができれば、より適切な根拠のある回答が可能になるでしょう。
フォークは、まだ維持されていると思われるパッケージに対して邪魔になりますが、作成者が一時的に欠落しています。煩わしいとは、元の作成者がメインラインでの作業を再開した後、他のプログラマーがあなたのフォークを手に取ってメインラインに戻らない可能性があることを意味します。
元の作者がHaskellコミュニティを離れたパッケージの場合、私の個人的な意見では、パッケージをさらに開発する場合は、パッケージをフォークする方がよいと思います。フォークは、後継者が元の問題よりも遅く、十分に文書化されていないために多くの開発者が更新したくないParsecで発生した問題など、後継者の問題を防ぎます。
カフェをフォローしないことを選択したかどうかに関係なく、すべての場合において、カフェで尋ねることが最善です。それでも、カフェはHaskellコミュニティの中心です。
質問の特定のケースでは、Hackageに関するものがコンパイルされるのは良いことですが、コンパイルする必要があるというルールはありません。壊れたパッケージに依存するパッケージは、壊れた依存関係の変更手順をフロントページに配置するだけで済みます。つまり、「このパッケージは壊れたLambdaThing-0.2.0に依存し、LambdaThingを修正してLambda.hsファイルに追加します。 「」
特定のパッケージと行方不明の特定の人については、メーリングリストを参照することをお勧めします。私は元の所有者からhaskell-src-metaパッケージを制御しましたが、リストとIRCに相談した後、Matt Morrowが何ヶ月も行方不明であり、その理由を誰も知らないと私に保証しました。
私の意見では、パッケージの所有権は、おそらくそうするためのコンセンサスがある場合にのみ変更する必要があります。または、少なくとも、パッケージを見つけるための努力が必要です。Hackageソフトウェアの開発バージョンでは、管理者だけがこの種の介入を行えるようにアクセス制御があると私は理解しています。