upgradepkg, post-install, but not rebooted, hardcoded /sbin/installpkg in upgradepkg... possible feature request/improvement?
by slvr32 from LinuxQuestions.org on (#5GRJ1)
This might be more of a feature request/improvement idea, but I noticed that the 'upgradepkg' script allows you to set a ROOT variable for an alternate location to check for package upgrades.
I happened to look at this when I put Slackware 14.2 (32-bit) on an older laptop, where I also happened to create a fresh usb stick install that included the latest 'patches' directory.
So, post-install, but opting to exit to a shell, rather than reboot, I was entertaining the possibility of upgrading the system with all the stuff from the patches directory.
I don't recall exactly, but I believe this left me with /mnt/sbin/upgradepkg already in the PATH, and I later noticed that /sbin/installpkg was hardcoded in the upgradepkg script, which I think is what kept the experiment from going well.
I noticed that ADM_DIR is built with ROOT in the upgradepkg script, in case ROOT is set, but I didn't take a longer look at the hardcoded /sbin/installpkg detail, or whether a temporary chroot or other variable/environment constructions for the path to installpkg would've possibly helped.
Of course doing the upgradepkg stuff on the first boot of the freshly installed system was another option.
I happened to look at this when I put Slackware 14.2 (32-bit) on an older laptop, where I also happened to create a fresh usb stick install that included the latest 'patches' directory.
So, post-install, but opting to exit to a shell, rather than reboot, I was entertaining the possibility of upgrading the system with all the stuff from the patches directory.
I don't recall exactly, but I believe this left me with /mnt/sbin/upgradepkg already in the PATH, and I later noticed that /sbin/installpkg was hardcoded in the upgradepkg script, which I think is what kept the experiment from going well.
I noticed that ADM_DIR is built with ROOT in the upgradepkg script, in case ROOT is set, but I didn't take a longer look at the hardcoded /sbin/installpkg detail, or whether a temporary chroot or other variable/environment constructions for the path to installpkg would've possibly helped.
Of course doing the upgradepkg stuff on the first boot of the freshly installed system was another option.