Following on from this post:
Actually, in my own opinion, there would be no better future for Puppy Linux than to adopt Void Linux package manager xbps as its core/default package management system. Yes, that would imply using Void Linux repos, but Void per above review, users have great control over producing repos of their own and Void package manager is full dependency-resolving and has proven to be bullet-proof.
At first sight that may 'sound' like Puppy Linux would then just be Void Linux, but no, not at all - I am only talking about adopting Void package manager, which has additional immediate benefit of being 100% dependency-resolving compatible with Void repos. Void package manager is supported upstream by a team of experienced developers; it is written in C so is inherently blazingly fast and efficient - why reinvent such a flexible wheel and what chance of ever achieving such a great result here as provided by xbps and thus available anyway???! (dpkg/apt too complex with too many Debian dependencies - xbps is self-contained and really distro-independent). What I'm implying is that the underlying system components, aside from that, can be pure Puppy, but with a big advantage - modes such as Pupmode 12, 13 and so on, can be implemented in a newly written Puppy initrd, but unlike the current implementation these modes could be implemented in a very distro/package-manage agnostic manner (rather than as current situation where the Puppy initrd needs all sort of Puppy config info from various Puppy-only config files for its operation). The rest of Puppy system remains pure Puppy, pup-volume monitoring and event handling and so on - there would be no need to use Void xbps to include any other Void system components (though runit might be a good choice for Puppy rather than sticking to stick-in-the-mud old sysVinit and a few others, to easily provide full multiuser support, which is main feature Puppy lacks, might be optionally worth including).
The creation by Puppy developers of a distro-agnostic boot initrd would also however open the doors to allow Puppy to provide/use alternative package managers to a default-provided xbps anyway - including, for example, Pkg, though perhaps Puppy-specific config files would have to be included for that option to still work (distrospecs and so?), but maybe even that requirement could be removed? Main point of Puppy Pkg option would be to allow Debian/Ubuntu/Slackware support alternatives provided by Pkg, but truth is, with a non-Puppy-configfile-dependent boot initrd, it becomes perfectly possible to use official Debian/Ubuntu apt package manager without dpkg database corruption as mixed PPM/dpkg attempts otherwise cause. It would also allow Puppy to use alternative initrd designs easily (since that agnostic initrd approach does not force the initrd to read Puppy config files). WeeDogLinux initrd, as simply an example of an 'agnostic' initrd, can already be used immediately to boot a Slackware root filesystem or a Slitaz root filesystem or any filesystems provided upstream by the likes of Debian, Ubuntu, or Devuan; not as simple or tidy or efficient as default of xbps but useful for 100% debian repo dependency-resolving capability). Current/traditional Puppy initrd, on the other hand relies on reading/embedding-info-for Puppy config files, so can only be easily used to boot traditional Puppy Linux itself, which really is an unnecessary and serious limitation in terms of flexibility and possibility. I'm certainly not suggesting WeeDogLinux initrd as a new initrd for future Puppy - no, not at all - Puppy should build its own new distro agnostic initrd to provide typical traditional Puppy functionality such as the Pupmodes I mentioned.
Anyway, woof-CE fine for now, but don't expect major Puppy advances through that template, whose main purpose always was simply to provide a template to keep traditional Puppy design alive and not at all ideal as a development environment for a continuing innovative Puppy that we would all like to see.
But, what the above scheme actually suggests is the production of a new ultra-flexible Puppy Linux that removes from this forum the mixed confusion of multiple very different distro designs, the Pups, the Dogs... a flexible new Puppy Linux could be configured to be any one of these and more. Yes, this is a suggestion that this is a time to unite rather than to simply collaborate.
wiak
