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