Have the uninstall script actually uninstall pi-apps

[theofficialgman]

Cool ideas?

Users with corrupted local pi-apps installs or other for other reasons may want to actually uninstall pi-apps. Some users say they "uninstall" pi-apps when actually all they do is run our uninstall script and install script. https://github.com/Botspot/pi-apps/issues/1920#issuecomment-1141730788 https://github.com/Botspot/pi-apps/issues/1842#issuecomment-1139288170 https://discord.com/channels/770629697909424159/770629878319022090/983068666738409502

Our instructions say to execute ~/pi-apps/uninstall

This does not actually remove the ~/pi-apps folder at all. and the install script for pi-apps does not attempt at re-downloading pi-apps from github as long as this folder exists, regardless if its content is good or not.

maybe we should consider either adding: A: a reinstall script, so that users who for whatever reason want to re-install, can do so and get the latest version of pi-apps, while still retaining their ~/pi-apps/data/status folder B: functionality to pi-apps install script to check for the integrity of the ~/pi-apps folder (whatever we decide "integrity" might mean)

[theofficialgman]

just for reference... the 3-months-updater is pretty close to what users would want from a "reinstall" script here is a slightly modified script

DIRECTORY=~/pi-apps
echo -e "\nYour Pi-Apps installation is somehow 3 months out-of-date.\nReinstalling Pi-Apps and saving the old version to ${DIRECTORY}-3-months-old...\n\n" 1>&2
cd $HOME
rm -rf ~/pi-apps-forced-update
command -v git >/dev/null || sudo apt install -y git
git clone "$(cat "${DIRECTORY}/etc/git_url")" pi-apps-forced-update 1>&2 && \
cp -af "${DIRECTORY}/data" ~/pi-apps-forced-update && \
cp -af "${DIRECTORY}/apps" ~/pi-apps-forced-update && \
mv -f "$DIRECTORY" "${DIRECTORY}-3-months-old" && \
mv -f ~/pi-apps-forced-update "$DIRECTORY"

#menu button
mkdir -p ~/.local/share/applications
echo "[Desktop Entry]
Name=Pi Apps
Comment=Raspberry Pi App Store for open source projects
Exec=${DIRECTORY}/gui
Icon=${DIRECTORY}/icons/logo.png
Terminal=false
Type=Application
Categories=Utility;
StartupNotify=true" > ~/.local/share/applications/pi-apps.desktop

#copy menu button to Desktop
cp -f ~/.local/share/applications/pi-apps.desktop ~/Desktop

#settings menu button
echo "[Desktop Entry]
Name=Pi Apps Settings
Comment=Configure Pi-Apps or create an App
Exec=${DIRECTORY}/settings
Icon=${DIRECTORY}/icons/settings.png
Terminal=false
Type=Application
Categories=Settings;
StartupNotify=true" > ~/.local/share/applications/pi-apps-settings.desktop

mkdir -p ~/.config/autostart
echo "[Desktop Entry]
Name=Pi Apps Updater
Exec=${DIRECTORY}/updater onboot
Icon=${DIRECTORY}/icons/logo.png
Terminal=false
Type=Application
X-GNOME-Autostart-enabled=true
Hidden=false
NoDisplay=false" > ~/.config/autostart/pi-apps-updater.desktop

[Botspot]

This would go hand-in-hand with a change to move Pi-Apps data to ~/.config.

And speaking of app-status, some apps install globally, others install locally, but many are partially installed both locally and globally. For example, some files may be created in /opt or /usr/bin, but the menu entry is in ~/.local/share/applications. This inconsistency breaks multi-user usability, so I've been considering making all apps install globally, then moving Pi-Apps app-status to a global location too. @theofficialgman, let me know your thoughts on that. It's not really possible to install all apps per-user, as many apps have dependencies or use debs.

[theofficialgman]

And speaking of app-status, some apps install globally, others install locally, but many are partially installed both locally and globally. For example, some files may be created in /opt or /usr/bin, but the menu entry is in ~/.local/share/applications. This inconsistency breaks multi-user usability, so I've been considering making all apps install globally, then moving Pi-Apps app-status to a global location too.

a lot of apps require the combined local and global installation. for example, as you said, debs are always a global installation, and many apps use these for dependencies, but MultiMC can not be installed globally, since its against how the software itself is written in terms of instance management and updating.

it is also a mistake to create apps in a global location with non-root permissions. for example, lets say I create an executable in /usr/bin/testexecutable with the ownership of gman (this is actually what most of ryanfortners debs do). a different user may not be able to run this executable because it does not belong to their namespace or root. many apps can not run properly as root and thus can't be installed globally.

For example, some files may be created in /opt or /usr/bin, but the menu entry is in ~/.local/share/applications.

for apps that do this, this is just a mistake of the creator. if it is only the .desktop file that is installed in a per user location (and the actual app files are global), then the .desktop file should be moved global.

This inconsistency breaks multi-user usability

I am aware of this, but we should also pick our battles first for the majority of users. likely over 80% of users still have the default pi username and this is the only user. another 19% have created a bullseye install since the piOS setup script was made and have made a unique username. its only that 1% (or likely even less than that) that even have multiple user folders.

[theofficialgman]

it is also a mistake to create apps in a global location with non-root permissions. for example, lets say I create an executable in /usr/bin/testexecutable with the ownership of gman (this is actually what most of ryanfortners debs do). a different user may not be able to run this executable because it does not belong to their namespace or root. many apps can not run properly as root and thus can't be installed globally.

For example, some files may be created in /opt or /usr/bin, but the menu entry is in ~/.local/share/applications.

My next priority will be to continue modifing pi-apps install/uninstall scripts to use global installation. For now, pi-apps itself can continue to store its files as it always has. The main usecase I have seen from one user in the discord was using pi-apps from one user (always the same user) to install applications with the expectation that all users would be able to access them.

While we would ideally transition pi-apps use use the global config directory /etc and be stored in the global binary and applications directories /usr/local/share/pi-apps and /usr/local/bin/pi-apps or /opt, doing so would require pi-apps to be run with root persmissions to write to any of these locations.