Motivation
When people try to keep an old puppy up to date eventuality at some point they might decide to upgrade a core package (e.g. glibc). Perhaps this is sufficient. However, one can upgrade more than this without a significant impacting the size of the system.
Options
Rather than just upgtading glibc I could take a minimal system that is approximatly less than 50MB and replace the core libs with those from the minimal system.
Some possible minimal systems are tinycore, Slatz, Bulldog (part of Fatdog64) and Wee Dog L_GO. Weedog L_GO rec.
The Fosapup version of Weedog L_GO caught my intrest here because of the apt/dpkg integration and its binary compatability with Fosapup.
I was also curious what wiak was doing with the weedog / firstrib type development and I thought that looking at the rootfs for this project might help me learn a bit about the development that wiak is doing.
The particular version of WDLGO i'm using is WDLGO_UbuntuFocal64. Here is what wiak says about it:
This distro a full-multiuser capable (including PAM) but an absolutely minimum dpkg/apt package manager UbuntuFocal64 compatible system. Except can be made much smaller using slimmed down firmware/modules (fwmods sfs) and deleting docs/man/locale pages etc.
However... being "an absolutely minimum dpkg/apt install" it is primarily provided for development/educational/experimental purposes. DISCLAIMER: USE ENTIRELY AT YOUR OWN RISK!
https://weedoglinux.rockedge.org/viewto ... ?p=332&i=1
The apt/dpkg integration is discussed in the following thread:
Released: WDLGO_UbuntuFocal64 mini-apt/dpkg experimental system
wiak discusses the WDLGO system here:
Under pre-release testing: new WDLGO systems
The actual core WDLGO system is only 27MB so adding UbuntuFocal64 apt/dpkg seems to approximately double the size. Therefore if I wanted a smaller upgrade I could stick to the core WDLGO system.
However, at some point there is deminishing returns when trimming systems. For instance the latest portable ungoogled chromium is 100MB and most modern puppies are over 300MB so even with apt/dpk included the overall size is relatively small.
That doesn't mean that I'm not interested in the core WDLGO system. However, as noted above there are a lot of options for minimal systems. So as an example In my next experiment I might try the same techniques with bulldog in order to provide FATDOG64 compatibility.
First experient Puli/Xenialand further motivation
In my first experient I am using the roots of
WDLGO_UbuntuFocal64 to upgrade core componets of PULI 7.3 (Xenial64). At this point my target system is a chroot or container guest type system and part of my motivation here is to experiment with running browsers in chroot and container type systems. The purpose of the upgrade is to be able to run ungoogled chromium in said system
So how to do the Upgrade
At a high level one upgrades by replacing packages with newer versions. Perhaps the info to do this is easily available (not sure) but I chose to start in a more adhock fashion which in the past has let me recover from accidently a second version of glibc.
Having multiple versions of glibc typically results in a segmentation fault unless one is careful to secret the incomparable versions.
Certainly in older versions of puppy such as Xenial64 the core libs such as glibc can be found in the /lib folder. What I did first was to manually move items in this folder to /lib/glib23 which duplicated the libs in WDLGO_UbuntuFocal64.
The most important ones to move were those associated with glibc 2.23.These libs are easy to identify because they have 2.23 in their name.That said for good measure I moved all libs in this folder which are part of WDLGO_UbuntuFocal64 so as to keep the updated libs. The code to do this has tje following form:
Code: Select all
while read line; do
mv $HARDLINKED_SFS/cont/lib/$line $HARDLINKED_SFS/cont/lib/glib23/$line
done <<EOF
ld-2.23.so
ld-linux-x86-64.so.2
...
EOF
The above process of moving these essentially removes them from places where they will likely be used by an application.These libs which we've moved are the ones that are most likely to break the system due to conflicting versions. These libs were delt with seperatly because there name differs by the version number.
Now that most of the problematic libs are out of the way the next step is to replace files in our modified puli/Xenial with thise of WDLGO_UbuntuFocal64. However, the replacement is not done for the /etc folder or the /root folder so as to not overwrite puppy configuration files.
In my case I'm doing the replacement by moving the old file to a new folder for reference and then hardlinking the file from WDLGO_UbuntuFocal64. The space of the moved Puli Xenial file is minimal because it is harlinked to a prestine puli/xenial system. In effect what I'm doing here is creating three systems here to of which are prestine and one which is hybird. Hardlinks are used to save space.
The code to do this is as follows:
Code: Select all
while read a_folder; do
mkdir -p "$MV_LOC/${a_folder}"
for a_file in $(ls -1a $FR_SOURCE/"$a_folder"); do
source_file="$FR_SOURCE/$a_folder/$a_file"
target_file="$TARGET/$a_folder/$a_file"
if [ -d "$source_file" ]; then
( cd "$(dirname "$source_file")";
echo "$(basename "$source_file")" | \
cpio -pdu "$(dirname "$target_file")" )
else
if [ ! -e "$target_file" ] || [ $(stat -c %s "$source_file") -gt $(stat -c %s "$target_file") ] || ! cmp --silent "$source_file" "$target_file"; then
if [ -e "$TARGET/$a_folder/$a_file" ]; then
mv "$TARGET/$a_folder/$a_file" "$MV_LOC/${a_folder}/$a_file"
fi
ln "$FR_SOURCE/$a_folder/$a_file" "$TARGET/$a_folder/$a_file"
fi
# fi
#done
fi
done
done <<EOF
lib64
var
var/log
...
EOF
Now for older versions of puppy such as Xenial the default version of some utilities is replaced by a script and the full version is renames to have the -FUL suffix. The next piece of code renames any full version of these utils supplied by WDLGO_UbuntuFocal64 with the -FULL suffix and then restores the script.
Code: Select all
while read a_file_rel_path; do
if [[ $(file "$TARGET/${a_file_rel_path}") != *ASCII* ]]; then
mv "$TARGET/${a_file_rel_path}-FULL" "$MV_LOC/${a_file_rel_path}-FULL"
mv "$TARGET/${a_file_rel_path}" "$TARGET/${a_file_rel_path}-FULL"
mv "$MV_LOC/${a_file_rel_path}" "$TARGET/${a_file_rel_path}"
fi
done <<EOF
sbin/losetup
bin/df
bin/umount
bin/mount
bin/ps
EOF
fi
Finally for older puppies such as Xenial the class loader needs to be located in the /lib folder. I accomplish this via symbolic links
Code: Select all
ln -s ./x86_64-linux-gnu/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2
ln -s ./x86_64-linux-gnu/ld-linux-x86-64.so.2 ld-linux-x86-64.so.1
but likely only one of these li ks is necessary.
The current status is that I'm able to chroot into this hybird system and the core utiloties apear to work. I will test other functionality later. Here is the code that I used to create the hybird system:
