From: Albert Y. C. Lai
To: glasgow-haskell-users@haskell.org Sent: Wed, April 27, 2011 9:53:38 PM Subject: Re: Package management
On 11-04-26 05:05 PM, Brandon Moore wrote:
There are already hashes to keep incompatible builds of a package separate. Would anything break if existing packages were left alone when a new version was installed? (perhaps preferring the most recent if a package flag specifies version but not hash).
Whether we allow multiple builds of same package same version, or allow multiple versions of same package, we face the same dilemmas:
First dilemma: If the package comes with C code, you get a name clash at the C level. Because C function names in such packages are unlikely to vary by version. Well, the linker sees two extern C functions both called get_current_timezone_seconds (real example from the time package), great.
Second dilemma: If the package comes with instance code like "instance Read (IO a)", you get overlapping instances.
Third dilemma: Data types and type classes defined by the package cannot be safely exchanged between two users because the two users depend on two different builds. Perhaps it is safe in most cases, but you can't be too sure.
All of these problems only happen if you try to use multiple versions of the package in the same program. Compilers and dependency solvers should continue to reject any attempt to use multiple versions of the same package. I am only worried about the more basic situation, where each program needs just one version of the library, but different programs might need it to be compiled against different versions of the dependencies. What can happen now is that you build B-1.0 and build A-1.3 against B-1.0 for one program that needs B-1.0, and then rebuild A-1.3 against B-2.0 to compile another program that needs B-2.0, but this unregisters the first version of A-1.3, which has to be recompiled if you want to build P1 again. Is there any reason not to leave both registered? Brandon Brandon