Simplified naming of Puppy files?

I have been playing with the concept of mix-n-match with Wary 0.7, and it certainly is interesting. There are four files that you use to build a Puppy, for example 'vmlinuz', 'initrd.gz', wary-070.sfs' and 'zw070341.sfs'. Of course, a Puppy can be built with the kernel drivers inside wary-070.sfs in which case the "zdrv" file does not exist and there are only three files. Further info on mix-n-match: http://distro.ibiblio.org/pub/linux/distributions/quirky/wary-070-mix-n-match/mix-n-match-readme.htm.

Then I started thinking about the reasons why two of those four files (or one of three) has versioned naming. I am sure that there were good reasons, but right now I can't think of any, but I can think of good reasons not to.

After all, 'vmlinuz' and 'initrd.gz' are not versioned, so why not extend that to all of them?

So, perhaps the four files could be named:

vmlinuz
initrd.gz
puppy.sfs
zdrv.sfs

Note that if this does turn out to be a very good idea, then I can develop the scripts to work with both old and new naming schemes, although it might get messy. Also there are lots of scripts out there that are based on the old naming. Perhaps I would have to do this in Quirky first, and make the change completely, no support for the old naming.

Very interesting! Your thoughts on this are most welcome...

---

Comments

Against
Username: Iguleder
This has some serious disadvantages, imho: 1) Puppy veterans are used to the old versioning scheme. 2) Lots of mess in Woof, remaster scripts and all system tools developed in the forums. 3) Might break compatibility with new/old tools. 4) Makes it harder to determine the Puppy version the files belong to. 5) Bad for multiple puppies (you have to mount puppy.sfs and examine etc/DISTRO_SPECS to see what puppy it belongs to. However, this surely has big advantages: 1) Many scripts need to be updated; this is a good chance to (finally) switch to Bash 4.x syntax in Woof. 2) It simplifies remastering scripts and package tools at the long-term. 3) More friendly, makes life easier for the average user, who uses one Puppy. Also, it removes the dash, which proved to be problematic with Joliet and DOS file names. Also, I have an idea: you could make the init scripts look for puppy.sfs and drop to $prefix-$version.sfs if it doesn't exist, so you have both. You could make the installers always rename the puppy.sfs they install to $prefix-$version.sfs - disadvantages 3,4,5 are gone. You could put another dialog, as the one that asks the user for a subdirectory, that asks the user whether he wants puppy.sfs or the old scheme, with a "RECOMMENDED: blah blah" notice below. The code that looks for puppy.sfs just needs to mount each puppy.sfs it finds and compare the MD5 of the /etc/DISTRO_SPECS of the initrd with the one from the SFS. If you put a notice that tells the user to use the old scheme in case he has multiple puppies (in the installers), the problem of slower booting is solved, no puppy.sfs matches are found. That's my 2c.

Re simplified naming
Username: BarryK
"Well, my reasoning is that you would not need md5sums or anything like that, as just like vmlinuz and initrd.gz, puppy.sfs and zdrv.sfs would be in the same location -- in the case of a frugal hd installation that would be in a subdirectory. If not, in a frugal hd installation with files at /, that would simply mean there can only be one installation at that location. This simplification could also be extended to the 'devx' SFS: [i]devx.sfs[/i]

For
Username: Iguleder
"Now that's a different story. Sounds like a good idea, I thought you wanted to keep the old code and just change the names. Now I understand what you meant earlier and I truly think the increased simplicity outweighs the disadvantages. It's a great idea, looking forward to it in Woof.

Good Idea
Username: Perthie
"Especially since it eliminates the hyphen/underscore problem. But when someone has multiple frugal installs, it's easy to know which is which by looking for the version number on the sfs file. Perhaps the ISO could also contain a dummy file whose name is based on the version number. The installer could then copy this additional file onto the drive for reference purposes.

Or Maybe
Username: Perthie
"The ISO could contain an info.txt file that contained the Puppy and kernel versions.

disk search
Username: jemimah
"Right now you can boot using the kernel and initrd on the CD (or usb, or floppy) but it will find your sfs files on disk. If you have multiple frugals on disk, I'm not sure how that would work. Maybe it could ask you which one, like how it does with multiple save files. However, if you do it that way, it becomes rather easy for the user to mix and match things that should not be mixed.

Re mix-n-match
Username: BarryK
"Jemimah, Yes, in the case of live-CD, if the sfs files are on hd then they would have to be in a directory that is named appropriately, such as /pup_431. This would be automatically created. In the case of frugals, the puppy.sfs, zdrv.sfs (and maybe devx.sfs) would all be in the same directory as the vmlinuz and initrd.gz. If the init boot script knows where it found the initrd.gz then it will also know where the sfs files are. As I mentioned, the limitation for frugal would be the top level '/' could only have one frugal installation. But the installer would not do this anyway, would always install in a directory. The installer could give the directory a recommended default name, ex /pup_431. In fact, there would be no searching anymore for the sfs files. But, still need to search for the 2fs/3fs 'pupsave' saved-session-files.

To Terryphi -- just use symlinks?
Username: Sit Heel Speak
"Terriphi wrote: [i]...they would have to be replicated in the psubdir for every version in a multi-boot system. This would create disk space problems for users with limited disk space.[/i] Can't you conserve the disk space, though, by keeping the add-on sfs's in just a single psubdir (or, for that matter, keep them in / if you like) and then create symlinks to them in every other psubdir you want to see them from?

Symlink solution will not work on NTFS file system
Username: Terryphi
"Sit Heel Speak wrote: [i]Can't you conserve the disk space, though, by keeping the add-on sfs's in just a single psubdir (or, for that matter, keep them in / if you like) and then create symlinks to them in every other psubdir you want to see them from?[/i] The problem is for those of us with several frugal installs dual booting with Windows. It is not possible to do symlinks on a NTFS file system.

Welcome
Username: Raffy
"This is very much a welcome development, as we need to simplify filenames for users who just have one Puppy (to start with, that is). Re: the /psubdir or / location of add-on sfs, can we have /sfsX as compromise? X will depend on the squashfilesystem version (like we have 3 and 4 now). of course, Puppy 4.3.1 and earlier used only /. I recall also that puplet makers did great with the pup_XXX.sfs naming system. (I wonder why this was changed to pup-XXX.sfs?) Along this line, can't we have these, too? vml_XXX ini_XXX.gz

Re names
Username: BarryK
"10.50pm here, I have been painting almost non-stop since 5am. My shoulder is just about falling off. Going home tomorrow. A problem with something like ini_XXX.gz is that we have different puplets that may have the same version number, so it is not a unique identifier. So there is no point having it. Just a thought that came into my head: pup_init.gz pup_main.sfs pup_zdrv.sfs ...fills up the 8+3 file format.

Tags: puppy