Puppy filenames
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.
id-string
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.
Compatibility
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.
Simplified 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.
DISTRO_SPECS file
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:
DISTRO_IDSTRING='w091100916185403'
DISTRO_PUPPYSFS='wary_091.sfs'
DISTRO_ZDRVSFS='zw091335.sfs'
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 /etc/rc.d/PUPSTATE.
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
Postscript
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.
Regards,
Barry Kauler
Sept. 2010