Talk:Software management

Please add the following if pertinent: https://github.com/sgerrand/alpine-pkg-glibc/

— Preceding unsigned comment added by Mekineer (talk • contribs) 11:04, 26 February 2024‎

---

I thought about the MegaCli wrapper. It should be possible to make it read the name it was called by and then launch the respective program (i.e. symlink any to-be-wrapped command to /var/lib/glibcstuff ...)

that way you get along with one wrapper script and symlinks to it in /usr/bin.

Another thing I couldnt figure is if it's important to use all 32bit versions?

And the download links for archlinux are not working because they forward wget to an https url. maybe this is some limitation in the default wget version. If i figure it out i'll do updates on this.

this is my /usr/bin/MegaCli now, using a minimal Debian install in /debian.

#!/bin/bash


KEYS="kernel.grsecurity.chroot_caps kernel.grsecurity.chroot_deny_chmod \
kernel.grsecurity.chroot_deny_chroot kernel.grsecurity.chroot_deny_fchdir \
kernel.grsecurity.chroot_deny_mknod kernel.grsecurity.chroot_deny_mount \
kernel.grsecurity.chroot_deny_pivot kernel.grsecurity.chroot_deny_shmat \
kernel.grsecurity.chroot_deny_sysctl kernel.grsecurity.chroot_deny_unix \
kernel.grsecurity.chroot_enforce_chdir kernel.grsecurity.chroot_findtask \
kernel.grsecurity.chroot_restrict_nice"

for key in $KEYS ; do
   sysctl -w ${key}=0 1>/dev/null
done


export CHROOT=/debian
user=$(whoami)
if [ "$user" != "root" ];then
echo "This script needs root access"
exit
fi
mount -t proc proc $CHROOT/proc/
mount --bind /dev/ $CHROOT/dev/
mount --bind /sys/ $CHROOT/sys/
#we may need dev and maybe proc too to use this program
chroot $CHROOT /opt/MegaRAID/MegaCli/MegaCli $@
umount $CHROOT/proc
umount $CHROOT/dev
umount $CHROOT/sys

— Preceding unsigned comment added by Darkfader (talk • contribs) 15:32, 11 July 2014‎

---

If you know how to relax grsecurity without using vanilla on Gentoo to allow PAM to not trigger a postinst error, you should edit the Gentoo section.

— Preceding unsigned comment added by Orson Teodoro (talk • contribs) 13:12, 3 February 2018‎

I'm unsure, if it's OK to add the following to page: will leave it here for reference: Here are the steps to run vscode, If running Sway on Alpine Linux.

1. From your Alpine Linux host, download Visual Studio Code from the official website https://code.visualstudio.com/docs/?dv=linux64_deb to your home folder.
2. Install the vscode as follows:

   $ distrobox enter my-debian --sudo apt-get install -f /home/<Username>/code_<version_number>_amd64.deb

3. Run vscode as follows:

   $ distrobox enter my-debian -- code --ozone-platform=wayland

--Prabuanand (talk) 11:10, 2 June 2025 (UTC)

AppImage

Dear John3-16, your edit changed the preferred method of running glibc applications from Flatpak to AppImage. Flathub is a known repository with a lot of applications that is guaranteed to work in Alpine Linux. I'm not aware of an equivalent reliable i.e trusted source for AppImages that is guaranteed to work in Alpine Linux. I tested a few from http://www.appimagehub.com and many did not work.

Please reconsider the above edit and consider restoring the Flatpak suggestion, until AppImages consistently work in Alpine Linux. -Prabuanand (talk) 13:43, 25 January 2026 (UTC)

Thank you very much for comparing use, which is helpful. It's good to feed your useful point into the wiki about so many AppImages currently failing in Alpine Linux, assuming that you had applied the gcompat layer instruction. In view of your examination and feedback, the order of the subsections and the preference for flatpaks have been restored, as flatpaks would therefore work out easier to install in the long run despite AppImages taking fewer steps to install when they do work. John3-16 (talk) 07:38, 26 January 2026 (UTC)