On Mon, Mar 8, 2010 at 2:31 PM, Maciej Piechotka
On Mon, 2010-03-08 at 15:37 +0100, Marc Weber wrote:
We can't expect package maintainers to test everything. So it must be people like you and me who fixes those changes.
Well. Except that it require bumping versions. Which according to hackage policy requires to fork a project (which makes it pointless in the first place)
This isn't quite that dire -- I've adopted the following practice when I encounter a cabal dependency issue: (a) identify the problem (eg: observing `cabal install foo` fails) (b) get the source via hackage: `cabal unpack foo` (c) fix the unpacked version, and increment the version number by adding a new level of detail (so, 3.1.0 becomes 3.1.0.1). This version number never leaves my system -- it only exists to keep my cabal/ghc-pkg consistent! (d) if possible, verify that the problem still exists in the project's actual source control (e) email the maintainer, and if possible, including a patch to the current head of the revision control system for the project. So far, it's worked pretty well :) Everyone I've sent patches to has been very responsive and helpful, often pushing updated versions to hackage by the end of the day.
The way to go is make hackage allow changing constraints on the fly notifying the author that he can update his repository.
You can, at times, do this by forcing constraints via cabal command line flags, or by installing packages with a version specification. $ cabal install foo-1.2.3 will install that specific version of foo. --Rogan
This will work in most cases.
Bumping versions because a dependency has changed is bad as well.
This will cause to much overhead (and it dosen't solve the problem because the old package is still wrong).
Specifying dependencies must be decoupled from bumping versions.
It's because dep specs do depend on the "world" which can change..
At least that's what I think.
Hmm. When I was returning home I thought about some wiki-like system that would allow to say 'Package X is compatible/not compatible with Y'.
Possibly something like: - Only the 'sure' deps are installed in default mode - When in 'expert' mode I can install any package which has not been marked as incompatible
Then I can say that I tested built and: - It failed to built - It failed the automatic tests (if they exists)/does not work - It success
So if there is versions: 0.7 0.8 0.9 1.0 1.0.1 1.1 1.2 1.3 1.4
And: - 0.8 failed to built - >=1.0 <1.1 was marked by author - 1.1 was marked as success - 1.3 failed to build
Then - In default/normal mode it can be used with 1.0, 1.0.1 and 1.1 - In expert mode 0.9 and 1.2 can be installed in addition to above - Any version can be installed in 'I'm feeling lucky' mode when I explicitly say package to ignore some restriction
Possibly it is needed to collect user karma (or possibly already account verification is sufficient).
If you're interested in Nix and hack-nix I can show you how everything works using an SSH session.
Ekhm... SSH?
Marc Weber
Regards
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe