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:


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:


.. and the spkg from:


In other words, the pkg file from:

+ pkgs/
+ base/
+ choic44x.zip

.. and the spkg from:

+ 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.


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.
Freedos-user mailing list

Reply via email to