Texaspilot wrote: Sun Dec 20, 2020 5:35 amS243a. Thank you. I found that in the package manager. Is there a button for a general system update, or is that it?
I will check out the midnight commander. I generally think I prefer working through the command line...
The puppy way of doing upgrades is to replace the base_sfs file (e.g. puppy_upupgg+d_20.10.sfs). Peebee uses xdelta to do updates. One applies the updates to the original iso. Then you can replace the sfs files on the iso with those on your system. However, this isn't a perfect update because some files might be blocked due to white-out files. Puppy will clean out these whiteout files if you boot with pfix=clean. You should backup your savefile prior to doing this.
Code: Select all
if [ "$pfix" ];then
for ONEFIX in $(echo -n "$pfix" | tr ',' ' ')
do
case $ONEFIX in
ram) PRAMONLY="yes";; #run in ram only (do not load ${DISTRO_FILE_PREFIX}save).
rdsh) RDSH="yes";; #exit to shell in initial ramdisk.
xorgwizard) PXORGWIZARD="yes";;#force xorgwizard for this session
nox) PNOX="yes";; #do not start X.
clean) PCLEAN="yes";; #force version upgrade and cleanup.
trim) PTRIM="yes";; #add "discard" to mount options if SSD
copy) PCOPY="yes";; #copy .sfs files into ram.
nocopy) PNOCOPY="yes";; #do not copy .sfs files into ram (default is copy if enough ram).
fsck) PFSCK="yes";; #do a fsck of ${DISTRO_FILE_PREFIX}save file.
fsckp) PFSCKP="yes";; #do fsck before first mount of ext partitions
[0-9]*) PIGNORELAST=$ONEFIX;; #blacklist last $ONEFIX folders (multisession).
*) echo "pfix=$ONEFIX is not a known boot parameter";;
esac
done
fi
/woof-CE/.../initrd-progs/0initrd/init#L796
Code: Select all
if [ "$PCLEAN" = "yes" ];then
#do upgrade processing
touch /tmp/version_update_flag
CURDIR="$(pwd)"
cd "$SAVE_LAYER"
#delete critical system files
#keep rc.local - user customisations and/or fixes.
echo "Removing $(ls ./lib/modules/$KERNELVER/modules.*)"
rm -f ./lib/modules/$KERNELVER/modules.*
RC_STUFF="$(ls ./etc/rc.d/rc.* | grep -v "/rc.local$" | tr '\n' ' ')"
rm -fv $RC_STUFF
rm -fv ./etc/rc.d/funct*
#iterate over all files in save
for ONE_FILE in $(find . \( -type f -or -type l \) -print); do
ONE_BASE="${ONE_FILE##*/}" #basename
if [ "${ONE_BASE:0:4}" = ".wh." ]; then #remove most whiteout files
[ "${ONE_BASE:4:4}" = ".wh." ] && continue #internal aufs files
[ "${ONE_FILE%/*}" = "./root/.config/autostart" ] && continue #keep autostart changes
echo "Removing ${ONE_FILE}"
rm -f "$ONE_FILE" #remove whiteout file
fi
done
cd "$CURDIR"
sync
fi
check_status 0
else
check_status 1
fi
/woof-CE/.../initrd-progs/0initrd/init#L483
Scottman is working on this problem:
"Updating builtin or system packages"
https://gitlab.com/sc0ttj/Pkg/-/issues/86
As an alternative to updating the base_sfs you can change the repos to a newer version of the compatible distro and then re-install all packages using the "-f" option on pkg. For built-in files you will will have to use the environmental variable "HIDE_BUILTINS=false". You'll also need to uninstall incomparable packages after upgrading to newer versions of these packages. PKG might not know to do this because the package in the compatible distro might have a different name than was given to the built-in package (e.g. glic vs libc6). This problem could be resolved by using aliases.
Anyway, presuming that you pull off the above, then you can remaster, replace the base_sfs with the remastered version. Delete any files that are in the bases_sfs and finally cleaning the whitout files by booting using the pfix=clean option. To say that this is unsupported is an understatement. I would say that it isn't implemented yet or even flagged to be implemented for that mater. That said, the basic structure of how to do this is there so it could be done.
However, the above procedure is more of a remaster approach. The puppy approach is to make builds reproducible by using woof-CE. This aproach is more maintainable and reduces possible issues of incompatibility that can result from upgrades. Many puppy distro developers often recommend that you start with a fresh save file when sufficient changes have been made to the distro. This is safer, cleaning and will result in a better performing system.
I think you will like the puppy way. The alternative is analogous to hording and can not only bog down your system but can at times cause things to at times not work. Since puppy aims to be a light-weight distro, an upgrading approach to development is a bad idea because lots of artifacts from the upgrade could be carried over that aren't needed.