Motivation
As, mentioned in another thread, I'm interested in updating older versions of puppy for the purposes of learning about the history of puppy (how they were done before) and also nostalgia. Also in some cases this may produce smaller systems than more modern systems.
This actually goes back to the roots of puppy because early on in puppies history older versions of software was chosen to help keep down the total size of puppy:
BK: This comes back to the way I built Puppy, file by file. I also made unfashionable choices, like going for Tcl/Tk. If you browse the menu in Puppy, you will find that the selection of programs is somewhat eclectic. A mixture of Xlib, Tcl/Tk, GTK1, GTK2, Ash/Bash apps. If I found a small program that did the job, I used it. Some of the apps seem very dated, for example, I use ROX-Filer version 1.2.2, which was the last GTK1 version, also the last version that used a simple and small mime-type handling system -- very old, but it is rock solid and works fine. Then there is Ical, a very old Tcl/Tk calendar program -- slightly quirky user interface, but still easy to use, and above all quite small.
On the other hand, Puppy has, where we think it necessary, the latest of some applications -- AbiWord for example. Gnumeric is scheduled to be updated to the latest version for Puppy 1.0.7 -- although 1.0.6 is just out the door, we Puppy developers are on a "heroin drip" and are now flat out on the next version -- there are typically 6 - 8 weeks between Puppy releases.
https://distrowatch.com/weekly.php?issue=20051114
With today's computers many of these choices made to keep the size of puppy small seem less relevant but there are still new computers sold with limited ram and storage (e.g. small laptops in the $300 price range) and many of the people on this forum still have older machines that may or may not be their primary computer.
Background
My experiment with revitalizing older puppies started with a relatively new puppy. I found that that could take @wiak wdlgo_focal64 and use it to update Puli/Xenial64. I did this for a chrooted/containerized system (test release here). Wiak's system is nice from a size perspective 20MB without apt/dpkg and 40MB with apt/dpkg (+dependencies) included and I'll likely use it as a reference as a minimal system.
That said, I don't always want a minimal system. In many cases I'm happy with a CLI system in the 100MB range with more full utilities and some extra tools like, perl, strace and midnight commander. CLI type systems form a nice staring point for a base of a distro and are excellent for remote operation of a computer. When graphical interfaces are added more bandwidth is required for remote operation and there will be some tradeoff between bandwidht and security. For instance xforwarding in trusted mode can run quite quickly but a high resolution VNC server may be slow. Additionaly, once we start getting into the world of graphical applications where do draw the line of what software to include vs exclude. While Modern puppies may typicaly range from 80MB to 500MB (just a guess) modern version of linux can start at sizes of 1GB of more (e.g. parrot OS security version).
I understand that the security version of Parrot OS is an application specific version but in 2014 (six years ago) you could by a convertable laptop with 8GB of ram, which had a good size screen for $1000 or less. Therefore, for many modern systems a 1GB OS may not be that large. In this context I don't consider a 100MB CLI system that large and I'm not advocating this as an ideal size but rather as a reference system where one can choose to either trim or expand upon.
Now all that said, I know that puppy 4 was released prior to my above laptop example. For example puppy 4.2.1 was released in 2009 (distro watch page) and I know that puppy is targeted towards older hardware than the release date of a given puppy. However, the amount of machines still in use that puppy 4.2.1 was targeted towards is dwindling and part of my objective here is to provide a way for people with newer machines to appreciate some of the prior puppy development.
Glibc in Lighthouse 4.43 / Puppy 4.3.1 / Attack Pup / Barebones431 / AnitaOS
As best I can tell Attack Pup (see thread) is based on Lighthouse 4.43 (see release notes), which is based on Puppy 4.3.1. Puppy 4 and derivatives typically have a glibc of about 2.6.1, with the exception of phonix, which has a glibc of 2.19, attack pup which has a glibc of 2.9 and Lighthouse 4.43 might have the save version of glibc as attack pup.
There Kernel Dependency of GlibC
Historically, puppy had many application specific versions. Today, this is seldom done. This is likely due to better better package manager support for binary compatible repos and more packages (and sfs files) built specifically for pupy. Attack Pup is one example of an application specific puppy but it is very old (puppy 4). One might wonder how much one can update a puppy from the puppy 4 era and still have compatibility with older libs.
One area of incompatibility could be between the kernel and the glibc library used. However, kernals 3.2 and newer (see can-new-glibc-versions-be-used-with-an-old-kernelthread) might be able to work with a fairly modern vern of glibc when both the kernal and glibc library are compiled with suitable parameters . Further Reading:
murga-linux: How to compile glibc?
kernel compiling in woof-ce
Various glibc and Linux kernel versions compatibility
Various glibc and Linux kernel versions compatibility
What is the relationship between kernel and GLibc?
So how new A GlibC can be Used with Puppy 4
There are two related questions, what's possible and what's a good idea. Given that precise 5.7.1 only has glibc-2.15 and will run the latest version of palemoon, perhaps that is sufficient for a legacy system. The total size of the sfs for percise 5.7.1 is only 151MB which isn't bad for a full system although it isn't as small as TazPup. Given that there is already a version of puppy 4 (i.e. phonex) that has a newer glibc than precise and precise is still usable for at least one modern browser one might wonder, "Why upgrade puppy 4 any further?".
My best answer I suppose, is to see what's possible. Give that I had success upgrading core libs of Puli/Xenial64 I thought, "Why not go back further?". And I was actually thinking about doing this for attack pup when I started using woof-next to build a core CLI system based on the Kali linux base but when I saw that it was a rolling repo, I thought it might be quite current and at first I thought it would be better to update a newer puppy (e.g. upupGG+D) with a rolling release. However, upupGG+D is actually newer than Kali-rolling so the update direction was backwards. One could use select packages in upupGG+D to update kalli-rolling. Kali linux is actually closer to fossaPup than upupGG+D but I already used a FossaPup based distro (i.e. wdlgo_focal64) to update a distro as old as Xenial and I thought, okay let's go older. Lets see if this will work with a puppy 4 distro like attack pup.
It turns out that you can do this but I can't say how well it will work and in what circumstances it will work. So far I've got the the desktop to work in a chroot based system but I'm still working on getting the panel (task bar in windows termination) to work and there is potentially some issues with icons to sort out.
So far I only had to symlink two libraries into the /lib folder. For the other libraries I was able to use the architecture specific folders like in a modern puppy. This is interesting because it gives me some incite into why puppy at one point had a multi-arch symlink hack.
I've only tested this as a chroot system so I can't promise that it would work as an independent system and I only tested the chroot in fatdog64-811 so I don't know how well the system will work as a chroot in older puppies. In some cases a kernal upgrade may be required.
The above was mostly background and in the subsequent posts, I will get more into how to accomplish the tasks mentioned above and what I learned.
. I'm not sure how new a version of glibc that I can use for these kernals but I suspect that both of them can be compiled to support a fairly new version of glibc.