theos / theos

A cross-platform suite of tools for building and deploying software for iOS and other platforms.
https://theos.dev
Other
4.5k stars 1.08k forks source link

[Bug]: Installer script can incorrectly detect Linux distro #832

Open CubeBag opened 1 week ago

CubeBag commented 1 week ago

What are the steps to reproduce this issue?

  1. Get a fresh Fedora computer or VM without theos installed
  2. sudo dnf install apt-utils
  3. Attempt to install theos with the installer script Issue presents itself

What happens?

Installer incorrectly recognizes the computer as Debian-based (due to the presence of the apt command), attempts to install all dependencies with apt, dies.

What were you expecting to happen?

Installer script should realize that the host machine is actually Red Hat based (Fedora) and install the dependencies with dnf instead.

Paste any relevant logs, error output, etc.

==> Theos Installer: Starting install...

==> Platform: Linux

==> Preparing to install dependencies. Please enter your password if prompted:
[sudo] password for cubeb: 
All packages are up to date.   
Error: Unable to locate package build-essential
Error: Unable to locate package fakeroot
Error: Unable to locate package rsync
Error: Unable to locate package curl
Error: Unable to locate package perl
Error: Unable to locate package zip
Error: Unable to locate package git
Error: Unable to locate package libxml2
==> Dependency install command seems to have encountered an error. Please see the log above.

Additional context

Line 325 of install-theos (the installer script) performs the check for if the command apt exists. I installed apt-utils since it provides the apt-ftparchive command (useful for messing with debs) but this package also includes apt which causes the Line 325 check to mis-identify this computer as Debian.

I confirmed that this is actually the root cause of the problem by inserting echo $DISTRO at line 336, and the installer script will proceed to output debian to the screen.

I think there ought to be a more robust method for determining the primary package manager that is meant to be used on the current device than simply seeing which command exists.

OS: Fedora Linux Asahi Remix 40 (KDE Plasma) aarch64 Host: Apple MacBook Pro (16-inch, M1 Max, 2021) Kernel: 6.11.8-400.asahi.fc40.aarch64+16k

What OS are you seeing the problem on?

Linux/WSL

What OS version does it have installed?

Fedora Linux Asahi Remix 40

What toolchain and version are you using?

N/A

Which SDK version are you using?

N/A

What OS is your client device running?

iOS

What OS version does it have installed?

N/A

Which device model is it?

N/A

Which jailbreak is it using (if relevant)?

No response

L1ghtmann commented 3 days ago

Hey, thanks for bringing this up. This has been on my list for some time. Apologies for the trouble. I can't recall if I tested this already or not, but what does the following print for you?

. /etc/os-release 
echo "Distro: $ID"

Edit: remembered my concern ... https://www.linux.org/docs/man5/os-release.html states that 'If not set, defaults to "ID=linux".' That and for distros like Ubuntu the value is not, say, 'debain'. In which case we'd also have to parse ID_LIKE per https://www.man7.org/linux/man-pages/man5/os-release.5.html. Hmm....