Re: [Freedos-user] FreeDOS Updater

[Mateusz V. <mat...@ma...>]

Hi,

As the thread became public, I will just add my offlist $0.02 (pasted from 
offlist mails) ;-)

On Friday 30 November 2007, Jim Hall wrote:
> .... so if I do that, I could deliver Entered-date ("last modified") in
> ctime format, so FDUPDATE always get dates like "Wed Nov 21 21:49:08
> 2007".

I agree, that would solve the probleme for ever. Not necessarily in the ctime 
format, but at least an format common to all LSM files... But ctime would be 
nice.
The problem is that all users will have to update their whole system the first 
time they launch FDUPDATE, as FDUPDATE will not be able to retrieve ctime 
informations from the local LSM files...

> But how do you know what package file to fetch? For a package named
> "foo" with version "3.1", the exe package would likely be FOO31X.ZIP
> and the src package would be FOO31S.ZIP. But not everyone uses the
> same version format, so that's a problem. And so you have package
> names that don't easily fit into 8.3, even simple cases like "choice"
> with version 4.4 ... how do you surmise the correct package name? I
> think I need to pass back a reference to the exe and src package
> names:

Why should we put all packages versions on the update server? An update server 
is meant to have the most up-to-date version. The package's version would 
appear only in the main xml file, but for example the CHOICE v4.4 packages 
would be named "CHOICEX.ZIP" and "CHOICES.ZIP", just like on the install CD.
If a new version of CHOICE appear, all to do is to replace the CHOICEX.ZIP and 
CHOICES.ZIP files, and update the XML content...

> On ibiblio, I could set up an "updates" subdirectory. So for the
> future FreeDOS 1.1 distribution, we'd have
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/u
>pdates/

I thought rather of an "unique" update server... FreeDOS updates haven't any 
version dependencies (like in Linux), if we get, say, a new CHOICEX package, 
all users will be invited to update it - no matter if they are running 
FreeDOS 1.0, FreeDOS beta 9, or anything else.
That way you could set up a server on www.freedos.org/fdupdate, and just add 
packages from time to time. The update URL will remain the same, and if 
anyone get FreeDOS v1.0 in ten years, he will be able to update it easily, as 
the update server will still be in the same place...

> Under "updates" we could have a separate subdirectory to separate exe
> packages ("pkg") from src packages ("spkg"). For example:
>
> ..../distributions/1.1/updates/pkgs/
> ..../distributions/1.1/updates/spkgs/

The packages may be all in the directory as well, but end up differently 
(ie. "CHOICEX" and "CHOICES")...
The package list on an installed system is stored in one directory too 
(in /freedos/packages)...

> That's not too different from how things are set up in the FreeDOS 1.0
> distribution. And at the "updates" directory level, I could drop in a
> data file for each disk set, that contains the list of packages for
> that set, using the format described above.
>
> ..../distributions/1.0/updates/base.lst
> ..../distributions/1.0/updates/devel.lst

But... An user may have installed only some packages from "devel", and some 
from "base", and even others, non-freedos tools (like wget)...
I would rather put all packages into one directory, along with one xml file... 
FDUPDATE will update only those packages which are already installed on the 
user's system anyway...

Bye!
Mateusz Viste