if that is your definition of compatible, you can never throw any
packages away
Is this a problem?
apparently, yes. no two versions of base with ghc, only the
newest set of core packages with each ghc release. and how
much time do you want to spend on finding, re-building, and
re-installing old packages everytime you move to a new machine?
it isn't (just) about space on a disk, it is about downloads
and management, not to mention sanity of mind;-)
a simpler way of putting the responsibility issue:
- every package writer is responsible for not reducing
the usability of his/her package at every update;
as with a function type, that works both ways:
use the simplest/newest dependencies available,
and keep your package useable by existing clients
so we're not just talking about packages at certain
points in their lifetime, we're talking about the lifetime
of packages in the context of their usage contexts/
package databases.
perhaps we should treat package databases as
distributed revision control system repos with
interlinked dependencies? then, just as darcs did,
we could focus on collections of patches that
create consistent new repos.
instead of "this is package P-2.11, deal with it",
it would be something like "add package P-2.11;
replace uses of P-2.{0-10} with uses of P-2.11;
remove any packages in that range; rebuild all
packages that used P-2.{0-7} as internal types
have changed; keep all packages P-1.* as this
is not a drop-in replacement for them".
claus
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
