Hackage Package version ranges
Hi, I maintain the Haskell package HLint. HLint depends on haskell-src-exts, cpphs, hscolour and uniplate, plus things which are shipped with GHC. For each of the external library dependencies, I have to specify a version constraint. For example, I developed HLint against cpphs-1.10 so I can write one of: 1) cpphs == 1.10.* 2) cpphs >= 1.10 I know (1) works, since I've tested it. However, every time I use (1) some distro (usually Arch) emails me to say they need wider ranges so they can get all their packages consistent. I then usually flip to (2). Then, sometime later, someone releases a new version of cpphs that changes the interface in a way that breaks HLint, and I get emails from users, and tend to go back to (1). Flip flopping between version constraints isn't a great idea. What should I do? Alternatively, if I could sign up to be emailed when something went wrong, I'd happily fix it. i.e. I'd like an email either when my package fails to compile against the latest version of all packages but within my constrained range, or when the latest version falls outside my constraint range. Thanks, Neil
On Tue, Feb 2, 2010 at 11:11 PM, Neil Mitchell
Alternatively, if I could sign up to be emailed when something went wrong, I'd happily fix it. i.e. I'd like an email either when my package fails to compile against the latest version of all packages but within my constrained range, or when the latest version falls outside my constraint range.
Getting correct dependency convergence through automatic building of packages and error-emails would be fairly interesting I think. The problem is not new as all software with dependencies are bound to run against its wall at some point - so perhaps there are some thoughts out there about what works and what doesn't. There is a reminiscence of buildbot in this as well. Generally, you want an environment where your package is built against all platforms currently under support at intervals to catch these kinds of errors. However, getting the infrastructure set up for this is a somewhat daunting task. -- J.
Alternatively, if I could sign up to be emailed when something went wrong, I'd happily fix it. i.e. I'd like an email either when my package fails to compile against the latest version of all packages but within my constrained range, or when the latest version falls outside my constraint range.
Getting correct dependency convergence through automatic building of packages and error-emails would be fairly interesting I think. The problem is not new as all software with dependencies are bound to run against its wall at some point - so perhaps there are some thoughts out there about what works and what doesn't.
Note that giving an error message when the latest constrained version fails to build is really hard, and requires building the package. An email simply saying "you say cpphs-1.10.* which excludes the most recent one which is cpphs-1.11" just requires parsing the cabal files, and is much easier. It's not as useful, but it might be a useful first step. Thanks, Neil
Neil Mitchell
However, every time I use (1) some distro (usually Arch) emails me to say they need wider ranges so they can get all their packages consistent.
Well, in Gentoo we normally resort to using sed to fix these kinds of things. If we can do it, I'm sure the Arch package managers are able to do so. It might be more annoying, but IMHO it's a bigger problem when a developer is too lax in constraints (since then we've got to tweak the constraints until we find ones that _do_ work). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
On Wed, Feb 3, 2010 at 2:13 AM, Ivan Lazar Miljenovic
Well, in Gentoo we normally resort to using sed to fix these kinds of things. If we can do it, I'm sure the Arch package managers are able to do so.
It might be more annoying, but IMHO it's a bigger problem when a developer is too lax in constraints (since then we've got to tweak the constraints until we find ones that _do_ work).
That is not a bad idea. The only problem I can see with that approach is the error-reports will be hard to understand if they are not filtered through the maintainer of said Gentoo-package. I usually configure my git-repositories to use 'git describe' and add a -dirty or -tainted to that if the tree is not clean when building. This tend to capture the problem of local patches and gives me a hint that something is altered :) -- J.
Jesper Louis Andersen
On Wed, Feb 3, 2010 at 2:13 AM, Ivan Lazar Miljenovic
Well, in Gentoo we normally resort to using sed to fix these kinds of things. If we can do it, I'm sure the Arch package managers are able to do so.
That is not a bad idea. The only problem I can see with that approach is the error-reports will be hard to understand if they are not filtered through the maintainer of said Gentoo-package. I usually configure my git-repositories to use 'git describe' and add a -dirty or -tainted to that if the tree is not clean when building. This tend to capture the problem of local patches and gives me a hint that something is altered :)
Well, I was only talking about it from a package management point of view, in which case users do come and complain to us first ;-) Note that the sed'ding is done via the Gentoo ebuild for the package, as are any patches we apply; as such there's no "fixed" tarball or anything floating around for any of these packages. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
participants (3)
-
Ivan Lazar Miljenovic -
Jesper Louis Andersen -
Neil Mitchell