ozboomer wrote: ↑Fri Aug 12, 2022 1:52 am[...]
I use different versions and distros of Puppy on different computers... and they are all frugal installations, as I find that makes it easier to move the installations between computers and it makes backups simpler.
I have a collection of Perl scripts that are used in all the installations.. and I currently load the distro’s devx.sfs at boot time so I can use the extra Perl modules it includes.
However, as time goes on, I’m constantly updating the Perl scripts and that often means I need to install extra Perl modules into each installation.
Is there a way that I could, for example, have an extra sfs file (let’s call it my_perl_devx.sfs) that just contains my extra Perl modules?
Then I could (conceivably) just take a ‘standard’ distro’s .iso file, create a frugal installation (with save file) that loads the ‘standard’ devx.sfs file and my_perl_devx.sfs and when I install the extra Perl modules, they would go into the my_perl_devx.sfs file.
This means I’d be able to move my personal Perl modules wherever I needed them.
[...]
The piece that's definitely not possible is "when I install the extra Perl modules, they would go into the my_perl_devx.sfs file.". That's because an sfs is a read-only archive, you can't write anything to it. So to update a perl module currently in my_perl_devx.sfs or to add a new module, you'd have to essentially re-create my_perl_devx.sfs. It isn't difficult to do, but it is some extra work. Updating my_perl_devx.sfs replaces installing/updating perl modules on all the computers you use.
The possible gotcha of bundling all perl modules into an sfs - @rockedge alluded to this issue - is incompatible perl or module versions or even machine architectures (you didn't say if all your computers run 64-bit puppies or if some are 32-bit).
Another possible gotcha is dependencies. When you update a module on PC A now, the module installer updates also all dependencies for that module. Then you update the same module on PC B, and the installer on PC B updates all dependencies for that module. The set of updated dependencies on PC A and the set of updated dependencies on PC B may not be the same. Now you want to replace the updates on PC A and PC B with just one update: my_perl_devx.sfs. In updating the sfs you need to know which module dependencies need updating for PC A _and_ for PC B.
Essentially you're trying to create a _portable_ perl library. That can work, I think, with a good change of success when all your PCs are homogenueous: same Puppy version, same machine architecture, same perl version, same devx. As each item changes accounting for all differences in a single portable library (my_perl_devx.sfs) adds complexity and lowers the chance of success.
Consider an alternative approach. Instead of eliminating updates on each PC, make them faster and predictable by creating a perl or shell script, alongside all other scripts of yours, that installs all dependencies for all your scripts. When some script will need updated modules, you will first update your dependency installer script to your liking, then run this installer script on a test computer to make sure it works. And when it does, you will run your installer script on all the other PCs, when you happen to be there, confident that the local system perl library will pull all hidden dependencies that the system needs.
@rockedge mentioned cpanminus. Are you familiar with that tool? It's a single-file portable perl module installer (it's a perl script). https://metacpan.org/pod/App::cpanminus look for "Installing the stand-alone executable". This script could also be added to your script collection.
