The `network-uri` flag is incorrect

[mniip]

Background: in 2014, the network package split part of its functionality into a separate network-uri package. The Network.URI module that was available in network <2.6 would no longer be available in network >=2.6, and instead would have to be obtained from network-uri >=2.6. To support this transition, a package that depends on Network.URI and wants to support old and new versions alike has to implement a cabal flag that ensures that either network <2.6 is in use, or network >=2.6, network-uri >=2.6 is in use.

However the literal encoding of this alternative as seen here:

HTTP/HTTP.cabal

Lines 139 to 142 in d1fddc5

	if flag(network-uri)
	Build-depends: network-uri == 2.6.*, network >= 2.6
	else
	Build-depends: network < 2.6

is insufficient. The real problem comes from having both network <2.6 and network-uri >=2.6 in the cabal build plan, and it's possible for this to happen if a package depends on HTTP and network-uri.

Said package might not support pre-split network <2.6, but it has no say in whether it's selected because it doesn't directly depend on network, only transitively via HTTP. This is to say that it's HTTP's job to prevent this from happening.

An example of this happens with cabal-install:

$ cabal install cabal-install-3.8.1.0 --with-compiler ghc-9.2.8 --constraint 'network ==2.5.0.0' --constraint 'network-uri ==2.6.4.2'
...
src/Distribution/Client/HttpUtils.hs:802:19: error:
    • Couldn't match type ‘network-2.5.0.0:Network.URI.URI’ with ‘URI’
      NB: ‘URI’
            is defined in ‘Network.URI’ in package ‘network-uri-2.6.4.2’
          ‘network-2.5.0.0:Network.URI.URI’
            is defined in ‘Network.URI’ in package ‘network-2.5.0.0’

To mitigate this (can't quite say "in anticipation of this"), a dummy network-uri-2.5.0.0 version was created: it contains no modules, and acts as a thing you can depend on to prevent >=2.6 versions of network-uri to be included in the plan. Its documentation also suggests the correct flag setup: https://hackage.haskell.org/package/network-uri

  if flag(network-uri)
    build-depends: network-uri >= 2.6, network >= 2.6
  else
    build-depends: network-uri < 2.6, network < 2.6

This problem affects HTTP >=4000.2.16.1 && <=4000.4.1, it was introduced all the way back in #73. Normally hackage revisions would be used to retroactively change dependency constraints, but in case of flags I'm not sure what can be done.

[hsenag]

Is this happening in the wild? Just trying to understand how much effort it's worth to do something about it - it would be low effort to fix for future versions but as you describe past versions are less certain.

[mniip]

I've run into this issue fairly quickly while trying to build my package with the cabal option --prefer-oldest, admittedly an option that is only used by few and only while they are figuring out what bounds to set on their package.

[hsenag]

Can you work around it with setting extra constraints on the command-line? I sympathise with the use case (and I've played with that option myself for similar reasons) but updating old versions would be a bunch of work.

[Bodigrim]

One won’t be able to add a new dependency through a revision, so I think there is not much to save except for future releases (which can probably just require newer network unconditionally).

[andreasabel]

Yes, we should drop support for the old network package and remove the flag.
network-2.6 was released a decade ago.
While we are at it, we can also drop support for GHC 7.