On Sun, Nov 29, 2009 at 4:41 PM, Duncan Coutts <[email protected]> wrote: > On Sun, 2009-11-29 at 09:55 -0800, Alexander Dunlap wrote: >> On Sun, Nov 29, 2009 at 5:37 AM, Duncan Coutts >> <[email protected]> wrote: >> > On Thu, 2009-11-26 at 16:40 -0500, David Menendez wrote: >> > >> >> The problem with this solution is that it doesn't scale. If we have M >> >> packages providing types and N packages providing classes, then we >> >> need M*N additional packages for orphans. >> >> >> >> The best long-term solution is probably extending Cabal to handle this >> >> more transparently, perhaps by allowing packages to depend on flagged >> >> versions of other packages (e.g., foomonad >= 4.0 && < 4.1 && HAS_MTL) >> > >> > Not going to happen. Such packages could not be translated into binary >> > distro packages. >> > >> > Duncan >> > >> >> Wouldn't the distro just choose one set of flags for each package and >> then other packages would either be satisfied or not satisfied based >> on which flags had been chosen? > > Here's the system I assumed you were talking about. You can tell me if I > misunderstood. > > Instead of having N * M packages, you have a package that provides > "optional" instances. For example package A defines a class and > optionally provides instances for types defined in B. If you select to > have it depend on B then the instances are provided, otherwise not. > > In a source based system this seems to work ok, you would provide > optional instances for all the packages you already happen to have > installed. Though if later you install another package that could have > had optional instances provided then you have to go recompiling things. > > It's slightly worse for binary packages because the distro has to decide > up front if they're going to provide the optional instances or not. > Since someone might need them then you end up picking the maximal set of > optional dependencies and you end up pulling in all sorts of apparently > unrelated packages. > > Then the other bit you suggested foomonad >= 4.0 && < 4.1 && HAS_MTL > would be needed to be able to express that you want a package that has > been built with a particular optional instance provided. This is the bit > that cannot be translated into packages in most distros. Yes you could > pick the flags up front, but you have to pick a single assignment that > satisfies everyone.
Well, that happens anyway with most packages since distros have to choose one set of flags that works. The proposal I was commenting on would just allow packages to depend on flags of other packages and so be explicit about this. > >> It seems to me that distros could even offer multiple options for the >> same package with different flags set. > > Most distros cannot handle installing multiple instances of the same > version of a package. Well, what I've seen is having different packages, i.e. foo-quickcheck, foo-no-quickcheck as separate packages. (Note that I can't take credit for suggesting the idea, I was just asking you about your objection.) Thanks! Alex _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
