I've often wanted a slimer base system for puppylinux, where only the most core files were in the base sfs and the other less core packages were moved to the adrv (or other sfs files). Having the package manager as the target application provides a design goal for this objective. This isn't necessarily the best design goal for a minimal system, rather it is the goal which suited my application.
My initial idea was that PuPnGo might make a good base system and that I could add a package manager to it from either tazpkg or x-slacko-slim. The reason that I thought that x-slacko slim might be a good choice is that mistfire has adapated petget in it to be able to download and install packages from more repo's then a typical puppy and this includes void and tinycore packages/repos.
PuPnGo is based on puppylinux 412, so the most compatible repos would be the puppylinux 412 repos or if I was looking for a comparable SliTaz repo I would choose version 4 of SliTaz (based on comparing bash versions). Obviously comparing glib versions would be more applicable but I haven't done this yet.
The reason that I looked at bash was that I thought an older version of bash might save significant space and I thought that PuPnGo's bash might be smaller since it may have been compiled against ulibc.
It turns out though that the bash in PuPnGo is not smaller. I presume that this is because it is statically compiled. However, at least in the case of slitaz the dependency libtinfo is only 128k. Moreover, in either case bash is only around 1MB and while packages of this size can add up, bash is fairly core in my opinion (although not required for tazpkg).
Anyway core PupNGo is around 8MB but that doesn't even include busybox! Perhaps PuPnGo pulls busybox from initrd. I'm not sure. The complete tazpkg with all it's dependencies is only 13MB.
The dpendencies of tazpkg are:
Code: Select all
busybox (824K)
slitaz-base-files (568K)
gettext-base (116K)
glibc-base (4M)
ncurses-common (120K)
Anyway, I'll look at how much things grow once I try to get a whole petget to work but for now here are some base systems for tazpkg:
tazpkg_all_deps 13MB (includes busybox, slitaz-base-files, glibc-base, ncurses-common)
tazpkg_slim 6.8MB (includes slitaz-base-files)
tazpkg_slimist_4 6MB (stripped down slitaz-base-files, using slitaz version 4 as the repo)
tazpkg_slimist_cooking 6MB (stripped down slitaz-base-files, using slitaz cooking as the repo. Cooking refers to rolling release version of Slitaz)
rootfs-tazpkg+bash 15.1MB (tazpkg_all_deps + bash + some preliminary files for petget)
The idea of tazpkg_slimist_4 was it might be a compatible starting point to combine with PuPnGo since as noted above the SliTaz 4 repo might have similar version of libraries as PupnGo. ALL SliTaZ files in the above systems are from either the cooking branch or the next32 branch. My intent was to use the next32 branch but by default the packages are configured to use the cooking branch so I'm not completely sure which versions I got.
These base systems are built using tazpkg since tazpkg allows you to install packages at an alternative root. The one exception being the last item on the above list (i.e. rootfs-tazpkg+bash) which was built by taking tazpkg_all_deps and then adding both bash-4.4.5 and libtinfo-5.9.tazpkg (a dependency for bash), in the SliTaz repo. These last two packages were added by some code that I'm working on:
install-min-pkgs.sh
mk-min-taz-functions.sh
The code is designed so that you can install packages from either a directory or a file. In the script, I use uextract to extract the files. I convert pet specs to tazpkg receipts and vis versa if one of them is available otherwise I use dir2pet to generate the pet specs. The downside here is that there is no option in dir2pet to not pack the archive. I'll have to do some mods to fix this.
Another downside is that uextract duplicates the extraction folder if it already exists but this is probably a bug in my code as I probably want to delete the old one first if it exists before running uextract.
Anyway, the above code (i.e. install-min-pkgs.sh) adds the information needed for both petget and tazpkg to know what is installed. The idea is that one can provide this type of info for one or multiple package managers:
Code: Select all
mkdir -p "$dest_root/root/.packages/builtin_files"
mkdir -p "$dest_root/var/lib/tazpkg/installed/$pkg_short_name"
for spec_type in $(eval 'echo "${'$spec_types_arry_name'[@]}"'); do
case "$spec_type" in
pet|.pet)
pet_specs_fm_dir "$source_dir" "$dest_root"/
cp "$source_dir/pet.specs" \
"$dest_root/root/.packages/builtin_files/$pkg_short_name"
;;
tazpkg)
tazpkg_specs_fm_dir "$source_dir"
cp "$source_dir/$pkg_name" "$dest_root/var/lib/tazpkg/installed/$pkg_short_name/files.list"
;;
esac
done
The sandbox helps to protect against coding errors where a source or destination root is not assigned properly, or if a symlink targets the system rootfs (remember that non relative symbolic links will point to the root system if one is not running in a chroot environment).
The purpose of the above systems is to have a small system that one can play with in a chroot environment to download packages and examine dependencies. All code is very preliminary so I recommend people wait before it is more mature before playing with it.
...). It would be necessary to introduce a version's selector in the scripts building in assembly language and to store a part of the more recent old versions...