Vibed broken OpenSSL dependency

[rracariu]

I have a package that depends on OpenSSL 1.1 ("openssl": "~>2.0.0+1.1.0h"), the new vibed release makes it impossible to use both as vibe.d defaults to 1.1 but doesn't explicitly sets it trough the dependencies.

The error is:

Unresolvable dependencies to package openssl:
  botan 1.12.10 depends on openssl ~>1.1.4
  foo ~master depends on openssl ~>2.0.0
  foo ~master depends on openssl ~>2.0.0
  vibe-d:tls 0.8.5 depends on openssl >=1.0.0+1.0.0e
  vibe-d:tls 0.8.5 depends on openssl ~>1
  vibe-d:tls 0.8.5 depends on openssl ~>1
  vibe-d:tls 0.8.5 depends on openssl ~>1
  vibe-d:tls 0.8.5 depends on openssl ~>1

I had to use the same "openssl": "~>2.0.0+1.1.0h" in the vibe-d:tls package in order for this to work.

[rracariu]

The way vibe-d:tls is configured ATM makes it impossible to work with OpenSSL on Windows.
Vibe claims OpenSSL 1.1 and links to it, but the actual dependency for the declarations is 1.0.0.

If you work with something that actually uses OpenSSL 1.1 then you suddenly can't, because dependencies don't match.

[schveiguy]

A vanilla vibe-d install doesn't work. I can't dub upgrade my existing projects. This is a severe issue. @s-ludwig

I can't figure out a correct configuration for generating a valid dub.selections.json file.

I'm not sure if this is something that botan broke or something that vibe-d needs to address.

steves@linuxmint-virtual-machine ~/Documents/testd/testvibe $ dub init -t vibe.d
Package recipe format (sdl/json) [json]: 
Name [testvibe]: 
Description [A simple vibe.d server application.]: 
Author name [Steven Schveighoffer]: 
License [proprietary]: 
Copyright string [Copyright © 2020, Steven Schveighoffer]: 
Add dependency (leave empty to skip) []: 
Successfully created an empty project in '/mnt/hgfs/Documents/testd/testvibe'.
Package successfully created in .
steves@linuxmint-virtual-machine ~/Documents/testd/testvibe $ dub
Unresolvable dependencies to package openssl:
  botan 1.12.11 depends on openssl ~>2.0.1
  vibe-d:tls 0.8.6 depends on openssl >=1.0.0+1.0.0e
  vibe-d:tls 0.8.6 depends on openssl ~>1
  vibe-d:tls 0.8.6 depends on openssl ~>1
  vibe-d:tls 0.8.6 depends on openssl ~>1
  vibe-d:tls 0.8.6 depends on openssl ~>1
steves@linuxmint-virtual-machine ~/Documents/testd/testvibe $

[schveiguy]

Note: I tried depending on botan v1.12.10. This also doesn't work, as its version of memutils is different than some other dependency.

[s-ludwig]

Workaround is to depend on botan < 1.12.11 and libasync < 0.8.5. I'm currently into finding a reproduction case to determine why the dependency resolution fails instead of falling back to the older versions.

See also vibe-d/eventcore#137

[schveiguy]

Would it make sense for botan to remove v1.12.11 and use 2.0.0 to switch the openssl dependency? @etcimon

[etcimon]

I've updated v1.12.11 to use the old version of OpenSSL. The 2.0.0 doesn't include the changes needed anyways in the buffer io structs, so once I make a pull request for that I'll change the version tag to v2.x afterwards

[s-ludwig]

Thanks, that has fixes the situation for now! I have also managed to prepare a small test case as a unit test in dub and know where the issue is. Now the only problem is finding a corresponding correction to the algorithm, which appears to be not very intuitive, unfortunately.

[etcimon]

The part after the + could be taken in consideration where both need to be a full version higher

[s-ludwig]

The issue that triggered the resolution failure is caused by a slightly wrong way in which the recursion through the dependency graph happens. This can cause one branch in the dependency graph to pick a version of a certain common dependency that will produce a conflict in another branch, while in reality an older version would have matched in both branches.

Unfortunately fixing this leads to an algorithm that is not as easily representable as a normal recursive algorithm AFAICS, as it requires repeated back tracking. I have a better picture of a possible solution now, though, so I hope to have something ready during the next days, as time permits.

[Geod24]

This doesn't manifest anymore.