[Haskell-cafe] instance Binary UTCTime (Was: Oprhan instances)

[Duncan Coutts]

On Sun, 2009-11-29 at 09:55 -0800, Alexander Dunlap wrote:
> On Sun, Nov 29, 2009 at 5:37 AM, Duncan Coutts
> <duncan.coutts at googlemail.com> 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.

> 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.

Duncan