On 11/30/07, Eric Auer <[EMAIL PROTECTED]> wrote: > > Hi! > > > Why should we put all packages versions on the update server? > > Actually I would not - I would put the package on ibiblio and > only let the update server know about the ibiblio URL. And as > more (!) users will update manually than with the updater, it > is pretty helpful to have ibiblio filenames which do contain > the full version number and full package name, even though that > will give many files names longer than 8+3. You can use the > WGET -O option to set a fixed short output file name for what > the updater will store on harddisk :-).
I would rather create a system that doesn't specifically rely on ibiblio as the install source. Yes, it's our primary site. But there are other mirror archives of the ibiblio files, and for some users in remote locations it might make more sense to point their FDUPDATE to one of the mirror sites. That's why, in my email, I was trying to keep things intentionally simple. If FDUPDATE knows the site & URI it's downloading from (call this the "repository") then all file references just fall under that. For example, the FreeDOS 1.1 updates repository might be: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/updates/ That's defined to the FDUPDATE program in some way, probably via an INI file. So FDUPDATE picks the list files from there, which contain references to pkg (exe) and spkg (src) files as, say, "choic44x.zip" (in "pkgs") and "choic44s.zip" (in "spkgs"). Assuming we just downloaded the list file for 'base', it's fairly trivial for FDUPDATE to glue things together to know to fetch the pkg file from: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/updates/pkgs/base/choic44x.zip .. and the spkg from: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/updates/spkgs/base/choic44s.zip In other words, the pkg file from: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/updates/ + pkgs/ + base/ + choic44x.zip .. and the spkg from: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/updates/ + spkgs/ + base/ + choic44s.zip 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. The zip files are not always guaranteed to have that directory structure - an author may simply have zipped up his/her work directory. > > I would rather put all packages into one directory > > I remember that this made the 1.0 "download any package > from 1.0" directory very user unfriendly. It contains way > too many files, with way too short names, so many users > got headaches when trying to download "diskcopy of 1.0" > or similar... Plus it did not tell them whether the 1.0 > version or the version in, say, the diskcopy directory > of ibiblio was newer. I suggest the solution to have all > versions of diskcopy only in the diskcopy directory, and > name them "diskcopy-0815x.zip" or similar instead of > "dkcp815x.zip" or "dskcpyx.zip" or similar ;-). No, I don't agree with all of that. Yes, we should organize the packages into a directory structure that makes sense. See my comments above. But the FDUPDATE program will be downloading these files using wget to a DOS filesystem. The pkgs and spkgs on the update server should be named using an 8.3 syntax. If we name the files on the update server using a non-8.3 syntax, then that means the FDUPDATE program would need to be modified to download the files into a systematically-named 8.3 syntax, something that makes sense for FDUPDATE's local cache of files-to-be-installed. Not saying that's a problem or a big obstacle, but that's the result of saying "let's name things without following 8.3". I think we should *not* name all pkgs for all versions of CHOICE as choicex.zip, and all spkgs as choices.zip. This makes it very difficult for someone to follow the progress of the versions of CHOICE that made it into the updates repository. It is important to ensure that each version may be identified separately. This is especially important with software covered under the GNU GPL, because the update server becomes the distribution point. -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 Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
