Issues when using several alternatives for external dependency on a given OS

[stcarrez]

Checklist

• [x] I've included the output of alr version.
• [x] I've included complete steps to reproduce my issue.

Describe the bug On Debian based systems, you can have different OS package names that provide a given external library. This depends on the OS version but also on some package alternatives. Examples:

• libcurl4-openssl-dev vs libcurl4-gnutls-dev: both are valid for the libcurl external library,
• libmariadb-dev for recent Debian version and libmariadbclient-dev for older ones

The following pull request https://github.com/alire-project/alire-index/pull/1085 suggest that we can express such alternatives by writting:

"debian|ubuntu" = ["libmariadb-dev",      # newer Debian versions
                   "libmariadbclient-dev" # older Debian versions
                   ]

However, only the first alternative is considered: if the second alternative is installed on the system, it is not checked and alr asks for the installation of the first alternative.

Following the libmariadb dependency fix, I would like to fix the libcurl dependency as follows:

"debian|ubuntu" = ["libcurl4-openssl-dev","libcurl4-gnutls-dev"]

To Reproduce Steps to reproduce the behavior:

1. Setup a libcurl dependency with:

    "debian|ubuntu" = ["libcurl4-openssl-dev","libcurl4-gnutls-dev"]
   

2. Install libcurl4-gnutls-dev on Linux
3. Run alr with libcurl => it tries to install libcurl4-openssl-dev
4. Change the libcurl dependency to:

    "debian|ubuntu" = ["libcurl4-gnutls-dev","libcurl4-openssl-dev"]
   

5. Run alr with libcurl => dependency is met
6. Uninstall libcurl4-gnutls-dev and replace it by libcurl4-openssl-dev
7. Run alr with libcurl => it tries to install libcurl4-gnutls-dev

Expected Behavior Dependencies are met when one of the two system package is installed.

alr version APPLICATION alr version: 2.1.0-dev+c864eeff libalire version: 2.1.0-dev+c864eeff compilation date: 2024-06-30 10:02:23 compiled with version: 12.1.0