slapt-get FAQ #17.
Hmm. Okay, bear with me here.

I think I see why gslapt would not let me add a local disk as a source.
I read the FAQ question. I was using the correct syntax to add the location of the disk. I had guessed correctly with that based upon using slackpkg in Slackware and Synaptic in PCLinuxOS.
However, seems the underlying slapt-get needs to find two files:
PACKAGES.TXT
CHECKSUMS.md5
PACKAGES.TXT is nowhere on the 13.0.2a disk.
Okay. I visited
http://download.salixos.org/i486/13.0/. Yes, there is a copy of PACKAGES.TXT. I downloaded the file with the idea that I would copy the ISO contents to a directory and add PACKAGES.TXT. From there I could create a new disk that should work with gslapt.
The format of the PACKAGES.TXT file is the same as in Slackware, with a pointer to the location of the file in the Salix repository file tree. For example: "./salix/l"
Yet the Salix CD does not use that same file tree structure as the online repository file tree. The CD contains the following directories only:
core
basic
full
The traditional "disk set" Slackware directories (a, ap, d, e, l, etc.) do not exist on the CD.
Therefore, if I understand correctly, gslapt and the underlying slapt-get would be unable to use the Salix CD as a local source because the locations provided in PACKAGES.TXT does not match the actual disk file system.
If I wanted to use the PACKAGES.TXT file found online, then the only way I could get gslapt to use a disk as a local repository would be to match the
http://download.salixos.org/i486/13.0/ file tree structure exactly.
Or I could try to generate my own PACKAGES.TXT based upon the existing Salix CD file tree structure. So I tried, using the shell script provided in the slapt-get FAQ No. 17.
I created a new directory, copied the contents of the CD, and then ran the shell script to create a new PACKAGES.TXT file. I created a new disk. Now my new Salix disk contains both of the files required by slapt-get/gslapt.
Then, to return to the original problem that prompted me to start this thread, I edited gslapt to use a local file system as my preferred respository source.
Worked like a hot knife on butter.
I think all of this never would have occured had I been able to add the disk as a source, which I could not because of the missing PACKAGES.TXT file.
When generating the ISO image for downloading, I would consider adding a PACKAGES.TXT file that matches the ISO file tree strcture. Then users could use their CDs as a local respository.
Non-technical users would just upgrade using the repositories with gslapt. I don't think that it would ever occur to them that they can upgrade by loop mounting an iso and upgrading packages from there.
That is a good point. Most users are unlikely to try using a disk image as a local repository. Yet I suspect more than a few would try using a physical disk.
Although the slapt-get FAQ addresses how to use a local respository, I think a nice gesture would be to provide the path name of a physical disk in the gslapt sources list. Leave the source unchecked. That way non-technical users have a chance of using their physical disk as a source.
My primary consideration for this idea is the flawed presumption that all users have a fast broadband connection. I had that displeasure for several years. I still remember those dial-up days with disdain. My only solution was to visit somebody in the city with a pocket full of blank CDs or an empty hard drive. I returned home with those disk images. For several years that was the only way I could test distros or update software packages.
Even for those people who have slow connectivity but buy CDs/DVDs, they need a local method to install and add packages when they receive the disks. Just an idea.
Oh yes, this is annoying

Would you please report it upstream?
Done.
