ePSXe and libcurl4

[arzardk]

Hello! Thank you for your work. I have a problem with ePSXe and Lutris. Lutris requires libcurl4 and ePSXe requires libcurl3, so if i installing ePSXe, Lutris will be uninstalled because it requires libcurl4. So, is there any way to have both of these programs installed without uninstalling neither of them?

Here is log from the terminal:
./ePSXe
/usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by ./ePSXe)
My distro is KDE neon (Ubuntu 18.04)

[bryceml]

Are you using the latest version of the script? If so, can you paste the contents of /etc/os-release ?

[linuxrecon]

Same problem here. Debian 10 (buster):

cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux buster/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

[brandleesee]

The code, as contributed by @bryceml , checks the VERSION_ID number. (reference: 68a031d)

From contents of /etc/os-release above, version is missing.

Maybe another command can give version number?

Example follows for Linux Mint:

rootusers@vm ~ $ cat /etc/os-release
NAME="Linux Mint"
VERSION="18.1 (Serena)"
ID=linuxmint
PRETTY_NAME="Linux Mint 18.1"
VERSION_ID="18.1"
VERSION_CODENAME=serena

Thank you.

[bryceml]

https://linuxconfig.org/check-what-debian-version-you-are-running-on-your-linux-system

Looking on debian buster (10) everything just says buster, not 10, so we may have to check a list of names with debian.

[brandleesee]

@arzardk can you please post your /etc/os-release as initially requested?
This so we can add support for KDE Neon....

[brandleesee]

@bryceml from your provided link, debian etc/os-release does have a VERSION_ID at least for vesion 9.
Could this be that from 10 onwards, version_id has been omitted?

[bryceml]

I believe it's that debian 10 is still in testing and won't be released as stable until likely this summer, maybe later. My guess is that it will have a VERSION_ID when it's released as stable.

[brandleesee]

I see. So for those who wish to use the script while still under testing, we do have to check a list of names...
Does it make sense to use a list of names instead of version numbers?
Already one has to differentiate version IDs between Ubuntu and Linux Mint...

[bryceml]

Debian testing will always contain "sid" somewhere in the name, we could check that and numbers pretty successfully I think.

Something like

if cat /etc/os-release|grep -qi sid
then 
  stuff
fi

It might be worth exploring our options more.

[brandleesee]

Updates to this comment are in bold.

Debian SID

I just updated the script with 68a031d#commitcomment-32485422, appreciated! This in preparation for the new arrangement to accommodate Sid branch.

Personally, I would go with only a list of names but if you deem fit to also keep version_id, then I will not object especially since your proposal is more professional...

Thus, should an instance be created for SID and also for Debian 10?
This to allow those using SID and also those who eventually upgrade to 10 to be compatible with the script.

---

KDE neon

Also, since we have been notified, a typical /etc/os-release for KDE Neon would be:
https://gitlab.com/zygoon/os-release-zoo/blob/master/kdeneon/kdeneon-5.9.txt
It seems to use the same versioning system of Ubuntu and is also based on the LTS 18.04, as is confirmed in same FAQ
https://neon.kde.org/faq#what-is-neon

NAME="KDE neon"
VERSION="5.9"
ID=neon
ID_LIKE="ubuntu debian"
PRETTY_NAME="KDE neon User Edition 5.9"
VERSION_ID="16.04"
HOME_URL="http://neon.kde.org/"
SUPPORT_URL="http://neon.kde.org/"
BUG_REPORT_URL="http://bugs.kde.org/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

Thus, in [ "$(. /etc/os-release ; echo $ID)" == "ubuntu" ], can "neon" be added (ID)?
Maybe to something like:

[ "$(. /etc/os-release ; echo $ID)" == "ubuntu" -o "neon"]

Reference: http://theunixshell.blogspot.com/2013/05/list-of-bash-conditional-statements.html

[brandleesee]

@arzardk & @linuxrecon
Kindly test so we can affirm that both KDE neon and Debian Sid are working well.
If positive, shall close until a new report is received re other distros switching to libcurl 4.
Thank you.

[bryceml]

I was thinking, an easy way to make this easily apply to all distros without managing them one by one is to check if libcurl4 is available, and if it is, manually install libcurl3 alongside it like we do for these newer distros.

If you look at which distros have libcurl4 it's exactly the ones that have problems with libcurl3 conflicting. https://pkgs.org/download/libcurl4

Instead of checking distros, we can do

if apt-cache show libcurl4 >/dev/null 2>/dev/null
then
  stuff here
fi

[bryceml]

if apt-cache show libcurl4 2>/dev/null|grep -q '^Package: libcurl4$'
then
  stuff here
fi

will work better because it will verify if the actual package is available instead of a virtual package if a virtual package were available.

[bryceml]

#10 is an option if we want to test it.

[brandleesee]

I agree wholeheartedly. This will reduce bloat in the script. Will revert to the previous block if we receive reports that it is not working as intended.

[brandleesee]

I am trying to get some feedback, so far I posted here:

• https://twitter.com/brandleesee/status/1119680122590777350
• https://twitter.com/brandleesee/status/1119853353356410880
• https://www.ngemu.com/threads/ubuntu-bionic-libcurl-so-4-curl_openssl_3-not-found.204577/post-2726479

[brandleesee]

will re-open if reports of conflicts between libcurl 3 and 4 are received