In the 'woof_gui' Woof GUI build system, there is now a help button for the new file naming, which brings up support/help_filenames.htm. But, I thought that it would be good to post that help page here for everyone to read:
The main Puppy files are:
vmlinuz, initrd.gz, puppy.sfs, zdrv.sfs
However, traditionally, versioning is put into the last two, for example:
vmlinuz, initrd.gz, pup_431.sfs, zp431335.sfs
...those last two names are intended to be unique for that build of Puppy, so they can be found at bootup.
The files vmlinuz and the two .sfs files shown above now have a 16-byte id-string appended to the files.
The first list is simplified names, with no versioning in the filenames, however, the 'init' boot script can read the id-string and uniquely
identify the files.
Having the id-string appended to vmlinuz is important for the 'init' boot script as it enables to find the boot partition (and path).
For the simplified .sfs names, again the id-string enables the correct files to be found.
For the traditional names, the id-string is used to find vmlinuz and hence the boot partition (and path), however the .sfs files are found in the traditional way, by their filenames. In other words, the appended id-string is not required, and need not be there.
There are may be some 3rd-party scripts that expect the traditional naming of the .sfs files, for example a CD-remaster program. So, for maximum compatibility, choose the traditional names.
It may also be argued that it is easier for the user to recognise the .sfs files if the filenames show versioned information.
There is one compatibility issue with the 'puppy.sfs' file. Some builds of Puppy, from Puppy 4.3.1 up to Lucid 5.1, name this file as
'pup-431.sfs' or 'lucid-510.sfs', however, the very latest Woof build system has returned to an underscore instead of a hyphen for the traditional name, so for example a recent build of Wary Puppy has 'wary_090.sfs'
Note, the reason for changing the '-' back to '_' is the original msdos f.s. canot handle '-' in filenames.
The main advantage of using the simplified names is the aesthetics of simple naming!
In practice, I don't think there is any problem with the files getting mixed up with the wrong ones. Normally, a frugal installation places files into a sub-directory whose name identifies what build of Puppy it is. Booting off CD, at first shutdown when it is offered to copy .sfs files off the CD to HD, they are now copied into a sub-directory.
Something to think about... Neither vmlinuz nor initrd.gz have versioning information in the filenames, yet they are specific to that build of Puppy. So, in what way is it any more difficult or inconvenient for the .sfs files to be named in the same non-versioned way?
The simplified names are currently there for experimental builds, to get some hands-on whether we like them. They are expected to be in Quirky 1.3.
The Woof '3builddistro' script (or checkbox in the 'woof_gui' GUI) enables to choose simplified or traditional filenames.
Whichever is chosen, the names are stored in the built Puppy, in /etc/DISTRO_SPECS. For example:
So, any script that wants to know what the names are can read these variables.
Woof 3builddistro also copies DISTRO_SPECS into the initrd.gz, so that the 'init' script can see what files to search for.
However, in a running Puppy, you can find out the filenames in the way that scripts have done before, by reading 'PUPSFS' and 'ZDRV' variables
In fact, to clarify the difference between these two sets of variables, I have put this comment into /etc/DISTRO_SPECS:
#Note, the .sfs files below are what the 'init' script in initrd.gz searches for,
#for the partition, path and actual files loaded, see PUPSFS and ZDRV in /etc/rc.d/PUPSTATE
The bottom line is that if you build Puppy with the traditional names,
then effectively everything is as before. The only thing really that developers and users have to be aware of (perhaps) is the reversion from '-' to '_'.
Under the hood though, the 'init' script is more efficient at finding the Puppy files, based on the id-string appended to 'vmlinuz'.
On the otherhand, if you build with the new names, everything should still "just work", but some 3rd-party scripts may need to be updated.
No comments posted yet.