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