alire
alire copied to clipboard
Issues when using several alternatives for external dependency on a given OS
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
vslibcurl4-gnutls-dev
: both are valid for thelibcurl
external library, -
libmariadb-dev
for recent Debian version andlibmariadbclient-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:
- Setup a
libcurl
dependency with:"debian|ubuntu" = ["libcurl4-openssl-dev","libcurl4-gnutls-dev"]
- Install
libcurl4-gnutls-dev
on Linux - Run
alr with libcurl
=> it tries to installlibcurl4-openssl-dev
- Change the
libcurl
dependency to:"debian|ubuntu" = ["libcurl4-gnutls-dev","libcurl4-openssl-dev"]
- Run
alr with libcurl
=> dependency is met - Uninstall
libcurl4-gnutls-dev
and replace it bylibcurl4-openssl-dev
- Run
alr with libcurl
=> it tries to installlibcurl4-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