5 ms·

> Not really; the upper bounds generally are speculative. Yes, an upper bound is still useful information. It says that a package is known to work with a cert

> Not really; the upper bounds generally are speculative. Yes, an upper bound is still useful information. It says that a package is known to work with a certain range of dependency versions. This is why I think cabal should support something like < for speculative upper bounds and <! for known failure upper bounds. Then we could have a flag for optionally ignoring speculative upper bounds when desired. > I wouldn't expect it to work for "years to come" in any event, though I can still download a binary of GHC 6.12.3. Hackage also keeps the entire package history so there's no reason things shouldn't build for years to come. I'm all for the fast moving nature of the Haskell ecosystem, but we also need things to be able to build over the long term and there's no reason we shouldn't be able to do that.

massysett 13y ago
"I can still download a binary of GHC 6.12.3." Which won't even work on current versions of Debian GNU/Linux because the soname for libgmp changed. "Hackage also keeps the entire package history so there's no reason things shouldn't build for years to come." No it doesn't. I had specified a dependency on a particular version of text, and it summarily vanished from Hackage. Even assuming that it's a worthwhile goal to make sure old software builds with current tools, upper bounds do nothing to get you there.
- mightybyte 13y ago
  > Which won't even work on current versions of Debian GNU/Linux because the soname for libgmp changed. Again, my argument assumes that you're not upgrading to current versions of things. Enterprise production-grade deployments often fix their OS version because of this. There's a reason RHEL is so far behind the most recent versions. If you are upgrading, then you'll be fixing these problems incrementally as you go along and it won't get out of hand. > No it doesn't. I had specified a dependency on a particular version of text You're making my point for me. It looks like you were probably depending on 0.11.1.4, which doesn't exist now. Your problem would not have happened if you had used an upper bound of "< 0.12" like the PVP says instead of locking down to one specific set of versions. If you had done that, cabal would have picked up subsequent 0.11 point releases which should have worked fine. Also, I can still download text-0.1 which is more than 5 years old.

massysett 13y ago

"I can still download a binary of GHC 6.12.3." Which won't even work on current versions of Debian GNU/Linux because the soname for libgmp changed. "Hackage also keeps the entire package history so there's no reason things shouldn't build for years to come." No it doesn't. I had specified a dependency on a particular version of text, and it summarily vanished from Hackage. Even assuming that it's a worthwhile goal to make sure old software builds with current tools, upper bounds do nothing to get you there.

mightybyte 13y ago
> Which won't even work on current versions of Debian GNU/Linux because the soname for libgmp changed. Again, my argument assumes that you're not upgrading to current versions of things. Enterprise production-grade deployments often fix their OS version because of this. There's a reason RHEL is so far behind the most recent versions. If you are upgrading, then you'll be fixing these problems incrementally as you go along and it won't get out of hand. > No it doesn't. I had specified a dependency on a particular version of text You're making my point for me. It looks like you were probably depending on 0.11.1.4, which doesn't exist now. Your problem would not have happened if you had used an upper bound of "< 0.12" like the PVP says instead of locking down to one specific set of versions. If you had done that, cabal would have picked up subsequent 0.11 point releases which should have worked fine. Also, I can still download text-0.1 which is more than 5 years old.