Ed_P wrote: ↑12 Sep 2023, 16:31
Doesn't loading so many versions of the same files make your booting process take longer? When I create a new mychanges.xzm module I rename the old one mychanges.xyzm to prevent it from loading but still being available to return to if the new one has problems.
Like I wrote:
Rava wrote: ↑12 Sep 2023, 12:52
It copies the resulting module (with added YYYY-MM-DD part of its name) into a certain folder and there is a symlink that gets changed to the currently created module name.
In my $PORTDIR/base are also two symlinks that point to the symlinks in the above folder, and that symlink again points to the most recent files, so I can use a multitude of porteus/base folders and all will use the most up-to-date settings-modules automatically.
The script that creates the most recent version also creates the symlink pointing to the most recent version.
I like having older versions available in the slim chance that one of these modules contains some weird error.
It is like so:
${PORTDIR}/base/991-usr_local_bin_RECENT.xzm -> /mnt/sda99/Porteus_modules/5.0/991-usr_local_bin_RECENT.xzm
and in /mnt/sda99/Porteus_modules/5.0/:
991-usr_local_bin_RECENT.xzm -> 991-usr_local_bin_2023-09-08.xzm
And thus all base folders where the 991-usr_local_bin_RECENT.xzm links to the link of /mnt/sda99/Porteus_modules/5.0/991-usr_local_bin_RECENT.xzm links always to the most recently created version - in my case at the moment, to 991-usr_local_bin_2023-09-08.xzm
Thus by having my settings-module-creating scripts create not only the most recent module, but also the always named identical symlink pointing to the most recent module, the modules can keep their YYYY-MM-DD info in their names, still, at every boot only the most recent version is loaded (as it should be, since it could happen you want settings files removed for some reason and not just updated; in that case loading older settings modules would mess that up).
The main trick is using a symlink to a symlink to a file.
The main part is I never have to bother updating the boot media / boot device /base/ folder since that symlink can stay the same and still always points to the most recently created module.
Added in 7 minutes 9 seconds:
And all that works flawlessly for years for me. As you can see, the first version got created around "2021-02-27 23:06" (time stamp of the symlink) and the most recent version of make-991-usr_local_bin.sh is 2022-11-08 21:30 - so unchanged in approx 10 months.
Because when you set it all up, you only have to use the cp command copying the file (with all its base folders) to the correct destination that got hardcoded into the script, then run the script (after you are satisfied that you updated or copied all new files you want included) and the most recent module got created, plus the symlink to that module.
Added in 8 minutes 54 seconds:
Of course when you want a boot media that holds all modules on itself so that it can be used at any PC, you still would have to manually update the settings-modules.
Scripting can do much, and symlink to symlink to file can do a great deal of (semi-automatic) work for you, but it cannot copy files to some random external partition it not knows about.
But if you need that functionality, you can always expand my make-991-usr_local_bin.sh script.