Add deps version bounds to generated specs

[QuLogic]

At the moment, build dependencies are added without version and runtime dependencies are added automatically due to shared library linkage. Additionally, something gets hashed into the library name causing them to be unique across all builds (even rpm revision bumps.)

I assume one of the reasons for the lack of versions is that Haskell packages usually supply both a minimum and a maximum which has not been supported in rpm. However, rust packages do a similar thing and those packagers either implemented or are going to make use of a recently implemented update to rpm that accepts multiple version specifications.

If lack of version constraints is one of the reasons here, it'd probably be good to look at what the Rust people do as these constant rebuilds are a really big holdup with updating Haskell things.

[juhp]

Sorry, I had completely missed this issue... :-(

We could do something about having bounds. But actually some people in the community are moving more in the opposite direction: eg Michael Snoymann recently had a proposal to drop bounds for Stackage! Bounds are actually a lot of trouble and hassle to maintain and Hackage revisions are really terrible.

So actually I have even been pondering about dropping bounds when building with ghc-rpm-macros. But this is still just an idea...

[peti]

Suppose I have a package set that contains doctest-0.13.0, and now I add a package to that which requires doctest >= 0.14. When someone tries to compile that package, then they'll (potentially) build and/or download a few dozen dependencies and eventually arrive at a point where the Cabal configure stage fails due to the missing dependency.

If that version constraint were specified in the spec file, then any attempt to compile that package would fail immediately, i.e. rpm would detect the missing dependency right away without compiling or downloading anything.

Therefore, I feel that having accurate version constraints available in the spec file would be a feature, i.e. it would make the life of package maintainers a little easier -- but not much. In practice, it doesn't make a huge difference to me whether a newly created build fails after 3 seconds or 30 seconds. It's gonna fail with pretty much the same level of information in either case.

Specifying accurate version constraints, on the other hand, is hard, because these version choices depend (potentially) on flags, compiler version, the versions of other dependencies, and so on and so forth. In general, it's not as easy as adding doctest >= 0.14 to the spec file; it's probably going to be a rather convoluted cascade of if-then-else statements with all kinds of crazy macros thrown into the mix.

It is doable, but it's a bit of an effort to pull off, and that you have pulled it off the actual gain in functionality is rather moderate. It's a quantitative difference, but not a qualitative one.

[QuLogic]

I don't understand why this is hard. The versions are already specified in the cabal file. Sure, some flags may cause different version requirements, but cabal-rpm already has to parse those to figure out the dependencies anyway.

The difference between 3 and 30 seconds is an order of magnitude. That might not mean much for one package, but it's a whole lot more for a bunch of packages.

[juhp]

But you see if we are just tracking Stackage LTS, then all the version checks have already been done. So carrying then in Fedora is mostly just a burden. If people find it helpful for specific cases or packages I don't mind that much though.

Already now patching .cabal files for Hackage revisions is major tedious pain-point IMHO.

[juhp]

(I think I should either try again using revised .cabal files with cblrpm, but it is kind of tedious to implement robustly I found the first time, or we can try dropping upper-bounds in ghc-rpm-macros.)

[peti]

I don't understand why this is hard.

Well, just make a PR then! :smile:

[juhp]

I could add: originally it was my long term plan to inherit bounds in .spec files using cabal-rpm but now with Stackage I am not very sure how useful or meaningful it is. Well there is a clear use-case: some packages get updated in Stackage LTS (or there is a new LTS release: in Fedora we don't freeze our tools yet to a specific LTS version) so it is still possible for us to get into the situation that @QuLogic describes, but those are edge or corner cases: packages in LTS are supposed to preserve API so it should be rare.