> > One more thing: I think the pkgs and spkgs for the update server > > should be assumed to be different than the zip files that we upload to > > ibiblio. A pkg and spkg have a particular meaning; they contain a > > particular directory structure. > > You are right, but it would be good if we could move towards a point > where all files have that directory structure. Otherwise, it will be > the exception, not the rule, that a downloaded zip file can be used > for updating. For all "normal" files, people now are forced to unzip > to a temp directory and spend time to sort the files to put them in > the right directories in their installed freedos.
It's not realistic to assume we will be able to have *every* zip file on the ibiblio archive to use the FreeDOS pkg directory structure. There are a few problems here: 1. Not all developers care about FreeDOS pkg structure. And it would be inappropriate of me to re-zip their release into a FreeDOS pkg-compatible structure. (It would be ok to create a pkg to put on the update server, but it is not ok to re-zip someone else's work before putting it in the general archive.) Also note that sometimes we put zip files on ibiblio that cannot be included on the FreeDOS distribution because they are not free for all, but are useful for some. The license for these "non-free" programs may prohibit repackaging. 2. There are historical versions on ibiblio. Does your suggestion imply that users should be able to find a historical version of a program that interests them, and should be able to install it using the pkg directory structure? 3. We may (at some later date) choose to change the FreeDOS pkg directory layout. As of today, no suggestions to do this have been made, but a year from now it's possible that we may want to change it. I don't want to re-zip everything on ibiblio to meet the new pkg standard. 4. Others who "roll their own distro" for themselves or for a distro they make available to others may not want to use our pkg directory layout, but instead go with something slightly different. But of all the above, #1 is the most significant and will be the reason we will not get 100% of all zip files into pkg format. It's a pipe dream to think otherwise. But I think we can assume it's ok for packages that are put on the update server () > > > But the FDUPDATE program will be downloading these files using > > wget to a DOS filesystem. > > Suggestion: wget -O choicex.zip http://foo/bar/choice-4.4-binary.zip > > This also makes sure that you have a "static" name of the > downloaded file (does not contain a version number) and also > a "readable" name (does contain the full name "choice") after > the download and a readable name including a readable version > number on the server :-). > > Remember that it is useful if people can find a package with > google. Bonnie probably has a lot of experience with this > when she tried to find new downloads of various packages... > She would not have found a "dkcp0815.zip" when looking for > "freedos diskcopy". Your suggestion works well when the package title is 7 characters or less. But you give an example of a package title that is 8 characters (DISKCOPY). Also DISKCOMP, CUTEMOUSE, GRAFTABL, FASTHELP, FDSHIELD, FDXMS286, GRAPHICS, LBACACHE, UNFORMAT ... all from the Base list. And FDUPDATE. :-) Also be aware of potential confusion between HIMEM and HIMEMX, which are both different packages. But since we don't seem to have pkg dependencies in FreeDOS pkgs, I suppose there is no reason for FDUPDATE to save the pkg to a recognizable filename. After all, it's only downloading into its local cache, and probably can be safely deleted from the cache after all updates are applied. So FDUPDATE could maintain an internal counter of files downloaded, and do this: wget -O 00000001.ZIP http://..../1.1/updates/pkgs/base/choic44x.zip You have room for 99,999,999 packages downloaded at once before you run out of (numerical) namespace. Not likely to reach this, but FDUPDATE could always switch to an alpha-numeric namespace if we think this will be a limitation. :-) -jh ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
