[Haskell-cafe] Handling absent maintainers
dagit at codersbase.com
Thu Jul 15 21:49:50 EDT 2010
On Thu, Jul 15, 2010 at 5:54 PM, Mark Wotton <mwotton at gmail.com> wrote:
> Hello all,
> I've recently had problems with haskell-src-meta. While it's a great
> package, it doesn't currently compile on GHC 6.12, and Matt Morrow
> doesn't seem to be around to push the version that does to Hackage.
> Our "one-world" approach with cabal seems to discourage forking as a
> casual act, so when a package that others rely on goes AWOL, it's very
> awkward to fix it.
> I can think of a few ways to get around my current problems:
> 1. upload haskell-src-meta-placeholder, or haskell-src-meta-mwotton,
> or something similar - this could be said to pollute the namespace,
> but would solve my immediate problem. I'd have to similarly specialise
> the chain of packages up to the one I actually want to use as well,
> 2. run my own hackage server and tell my users to use that instead.
> 3. ... profit?
> Ideally, I'd like to be able to say something like "cabal install
> my-hacked-package --as original-package" - are there fundamental
> reasons that wouldn't be possible, or a bad idea?
I haven't (yet) run into a completely AWOL maintainer. Usually I can
contact the maintainer and offer to upload a new version for them. I'm
currently in this role with Takusen. I'm not the Takusen maintainer, but I
expect to be uploading the next version soon as it looks like I've been
I've had this happen with a couple other packages and it was always a
similar situation. Negotiate with the listed maintainer to do an upload on
their behalf. I've found that offering to do the work for them usually
helps tremendously. And it makes a lot of practical sense.
Now, what you're proposing is interesting. I believe github/patch-tag have
this model? Everyone has their own branch of everything they contribute to,
listed right on the website? This is inline with another idea I've heard
where we'd have a 'stable' hackage and 'unstable/dev' versions. But, how
does this work for resolving and communicating dependencies?
On a philosophical note about cabal, cabal wants to be able to reason
statically about the API (types, functions, modules) a package provides. So
flags should primarily be used to configure platform specific bits necessary
for compilation or implementation details, but not to change the API of a
compiled library. From this point of view it seems to me that what your
describing needs to be baked into either the package name or the version --
that is whatever cabal is going to look at during constraint satisfaction.
I like your idea and I'd like to hear more about how we could accomplish it
within the philosophical framework that cabal already has.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe