On 08 August 2005 07:45, Brian Smith wrote:
Let's say we have multiple versions of a package installed: a-1.0 a-1.0.1 a-1.1 a-2.0 and that we have the following Build-Depends in a package description: Build-Depends: a >= 1.0
Now, when I configure, Cabal will choose a-2.0 as the package to build with. However, it makes more sense to choose a-1.0 by default instead.
I don't agree, there is just as much potential for breakage with this choice, and it will cause problems if someone is trying to upgrade their system incrementally. If I have both a-1.0 and a-2.0 installed, I probably don't want any new dependencies on a-1.0, because I want to delete it at some point.
* Currently, if we change the program to require a feature that is in a-2.0, but not in a-1.0, then the build will succeed for _us_, but it will fail unexpectedly for someone else that has only a-1.0. However, if Cabal instead chose the minimum version available, then, _our_ build would fail, and we would know that we need to either remove the dependency on the a-2.0 feature or increase the version specified in Build-depends.
Conversely, if the author builds with a-1.0, and the recipient builds with a-2.0 and version 2.0 is not backwards compatible, then the package will break. If the package depends on a-1.0 rather than a>=1.0, then it should say so.
* a-2.0 is not guarenteed to be 100% backwards-compatible with a-1.0. Even a-1.0.1 is not guarenteed to be backwards-compatible. So, if the original author was really testing with a-1.0, then we are more likely to run into problems with a-2.0 (or even a-1.0.1) than a-1.0.
This is true, but most people will not have multiple versions of a package installed. Furthermore, we'd like to discover problems early, and this just hides the bug in the dependency specification. Cheers, Simon