Based on my own misadventures and Albert Y. C. Lai's SICP (http://www.vex.net/~trebla/haskell/sicp.xhtml) it seems the that root of all install problems is that reinstalling a particular version of a particular package deletes any other existing builds of that version, even if other packages already depend on them. Deleting perfectly good versions seems to be the root of all package management problems. 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). For example, It seems the butterfly effect http://cdsmith.wordpress.com/2011/01/17/the-butterfly-effect-in-cabal/ could be avoided if the package database was allowed to simultaneously contain a "twittertags-1.0.0-hashA" and "twittertags-1.0.0-hashB" built against different dependencies. The obvious difficulty is a little more trouble to manually specify packages. Are there any other problems with this idea? Brandon
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.
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
On Tue, 2011-04-26 at 14:05 -0700, Brandon Moore wrote:
Based on my own misadventures and Albert Y. C. Lai's SICP (http://www.vex.net/~trebla/haskell/sicp.xhtml) it seems the that root of all install problems is that reinstalling a particular version of a particular package deletes any other existing builds of that version, even if other packages already depend on them.
Deleting perfectly good versions seems to be the root of all package management problems.
Yes.
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).
That is the nix solution. It is also my favoured long term solution.
The obvious difficulty is a little more trouble to manually specify packages. Are there any other problems with this idea?
See nix and how it handles the configuration and policy issues thrown up by allowing multiple instances of the same version of each package. For example, they introduce the notion of a package environment which is a subset of the universe of installed packages. Duncan
participants (3)
-
Albert Y. C. Lai -
Brandon Moore -
Duncan Coutts