I think you're making this way harder than it really is. What 99% of people need is that hackage packages builds with the latest haskell platform, and/or with bleeding edge ghc, and with the latest versions of its dependencies.
Thus for every dependency there is only one possible version - the latest one, and there are only a couple of compilers. Having "special interest groups" for ghc 6.12 support and old versions of text is fine, but I think it is a pretty uninteresting problem to solve. Likewise, supporting/fixing packages where the author for some reason *requires* use of a non-current version of some other package is also quite uninteresting (or at least outside the scope of my needs). Such a package is basically just a relic. Alexander On 30 August 2012 22:26, Jay Sulzberger <j...@panix.com> wrote: > > > On Thu, 30 Aug 2012, Alexander Kjeldaas <alexander.kjeld...@gmail.com> > wrote: > > This is very unfortunate, but this is crucially a tooling issue. I am >> going to wave my hands, but.. >> >> Ignore the mapreduce in the following video, but look at the use of clang >> to do automatic refactoring of C++. This is *incredibly* powerful in >> dealing with updates to APIs. >> >> http://www.llvm.org/devmtg/**2011-11/videos/Carruth_** >> ClangMapReduce-desktop.mp4<http://www.llvm.org/devmtg/2011-11/videos/Carruth_ClangMapReduce-desktop.mp4> >> >> But without all that fancy tech, *just* having all of Hackage source code >> in one repository and using perl/regexps, fixing these types of issues is >> O(1) instead of O(n). >> >> All of the issues you mention seems to be fixable by a few lines of perl >> *if we had the repository*. >> > > Better to do this with sexps. > > ad repositories: Part of the general problem of managing a > repository is close to the problem of inferring a good type for > (the value of) an expression. The style of constraints is > similar. Now the design problem is: > > 1. Arrange a general system for the specification of the > constraints. > > 2. Design a systematic way of giving both advice and direct > commands to the system. This subsystem would be used to set > up the default policy. > > 3. Choose a constraint solver. > > Maybe worth looking at: > > > http://en.wikipedia.org/wiki/**Nix_package_manager<http://en.wikipedia.org/wiki/Nix_package_manager> > [page was last modified on 17 July 2012 at 20:20] > > oo--JS. > > > >> [a few hours later] >> >> Actually, I went and downloaded all of hackage, put it into a git >> repository and fixed these issues: >> >> Fix catch >> perl -ni -e 'print unless /import Prelude hiding \(catch\)/' $(git grep >> 'import Prelude hiding (catch)') >> >> Fix CInt constructors (lots of other stuff from Foreign.C.Types not fixed >> though) >> perl -p -i -e 's/^import Foreign.C.Types(.*)CInt([^(])/**import >> Foreign.C.Types${1}CInt(..)${**1}/g' $(git grep -l '^import.*CInt') >> >> Fix bytestring versioning >> perl -p -i -e 's/bytestring( +)>=([0-9. &]+)<([ >> ]*)0.10/bytestring$1>=$2<${3}**0.11/g' $(git grep 'bytestring.*< *0\.') >> >> Patch to hackage: >> http://ge.tt/6Cb5ErM/v/0 >> >> I understand that this doesn't help anyone, but if there was a way fix, >> upload, and get *consensus* on a few regexps like this, then doing API >> changes wouldn't be such a headache. >> >> Alexander >> >> On 30 August 2012 07:26, Bryan O'Sullivan <b...@serpentine.com> wrote: >> >> Since the release of the GHC 7.6 RC, I've been going through my packages >>> and fixing up build problems so that people who upgrade to 7.6 will have >>> a >>> smooth ride. >>> >>> Sad to say, my experience of 7.6 is that it has felt like a particularly >>> rough release for backwards incompatibility. I wanted to quantify the >>> pain, >>> so I did some research, and here's what I found. >>> >>> I maintain 25 open source Haskell packages. Of these, the majority have >>> needed updates due to the GHC 7.6 release: >>> >>> - base16-bytestring >>> - blaze-textual >>> - bloomfilter >>> - configurator >>> - criterion >>> - double-conversion >>> - filemanip >>> - HDBC-mysql >>> - mwc-random >>> - pcap >>> - pool >>> - riak-haskell-client >>> - snappy >>> - text >>> - text-format >>> - text-icu >>> >>> >>> That's 16 out of 25 packages I've had to update. I've also either >>> reported >>> bugs on, or had to fix, several other people's packages along the way >>> (maybe four?). So let's say I've run into problems with 20 out of the >>> combined 29 packages of mine and my upstreams. >>> >>> The reasons for these problems fall into three bins: >>> >>> - Prelude no longer exports catch, so a lot of "import Prelude hiding >>> (catch)" had to change. >>> - The FFI now requires constructors to be visible, so "CInt" has to be >>> imported as "CInt(..)". >>> - bytestring finally got bumped to 0.10, so many upper bounds had to >>> be relaxed (*cf* my suggestion that the upper-bounds-by-default policy >>> >>> is destructive). >>> >>> It has been a lot of work to test 29 packages, and then modify, rebuild, >>> and release 20 of them. It has consumed most of my limited free time for >>> almost two weeks. Worse, this has felt like make-work, of no practical >>> benefit to anyone beyond scrambling to restore the status quo ante. >>> >>> If over half of my packages needed fixing, I'm alarmed at the thought of >>> the effects on the rest of Hackage. >>> >>> I'm torn over this. I understand and agree with the impetus to improve >>> the >>> platform by tidying things up, and yet just two seemingly innocuous >>> changes >>> (catch and FFI) have forced me to do a bunch of running to stand still. >>> >>> I don't have any suggestions about what to do; I know that it's hard to >>> estimate the downstream effects of what look like small changes. And so >>> I'm >>> not exactly complaining. Call this an unhappy data point. >>> >>> ______________________________**_________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/**mailman/listinfo/haskell-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe> >>> >>> >>> >> > ______________________________**_________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/**mailman/listinfo/haskell-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe> >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe