On Mon, Mar 8, 2010 at 2:31 PM, Maciej Piechotka <uzytkown...@gmail.com> wrote: > 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 > > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe