On Sun, May 11, 2014 at 11:10 PM, Roman Cheplyaka
In this case I'm speaking as an open source library author, whose library depends on temporary.
So no, cabal freeze can't help here.
Roman
Have you considered autoconf? I know it is a painful syntax due to the macro processing, but it is wicked powerful. Rather than futz around with version numbers or having to magically predict the future, I just have macros like HC_CHECK_MODULE(Data.Foo,[baz::Int],[packagea,packageb,packagec]) and it will check each package for the module with the id of the right type and include the first it finds. If a package maintainer changes behavior that in their mind wasn't version breaking that affects me and decides not to bump a version number it doesn't matter one bit, I just add a line in my conf file to check for the bug and adapt. For more complicated things, I can check things like whether instances are defined, size of types and whatnot, all one liners. The best part is no need for version number archeology or having to wait on anyone else or risk breaking someone else. Any changes monotonically increase the portability without breaking it for others. If a package i need is "broken", and i want to release now, I just include a patch to the third party package in my dist, autoconf checks if it is needed and applies it before building the dependency, I have the situation resolved in fifteen minutes rather than having to wait on anyone blocking my release. and it is backwards and forwards compatible, since it checks whether the patch is needed it won't apply it to older versions and when the issue is fixed upstream then it is just no longer applied. I do have a longer term project dealing with autoconfs shortcomings in a general way (mainly its sh/unix dependence and m4 quirkyness), autoconf's pretty awful in some ways, but not nearly as bad as the attempts to replace it. John -- John Meacham - http://notanumber.net/