On 11/30/07, Mateusz Viste <[EMAIL PROTECTED]> wrote:
> Hello!
>
> I wrote an online updater for FreeDOS. It's purpose is to download an index
> file from the FreeDOS Update server, and compare the list of packages which
> are on the server whith the packages installed on the system. If it find
> any "remote" package with a different version than the local one, it will
> propose to update it.
> The whole program isn't finished yet (v0.50), but is working fine. It have a
> pre-configured update URL pointing
> to "http://mateusz.viste.free.fr/fdupdate";, that's where I am storing the
> newest freedos packages (the url may changes later to something
> more "official").
> [...]
This project has me very excited about FreeDOS!! This makes it easier
on users who want to stay current on software, even during times when
we haven't released a new version of FreeDOS in a while. I love it!
Mateusz & I have also been working on this off-list. A few thoughts,
to bring the rest of you up to date:
When deciding what packages need updating, the easiest thing would be
to compare the date & version of the installed package vs what's
available on the update server (using an LSM or some other
identifier.) But dates are a problem. Mostly we have been using dates
like "2007-11-26", but there are a few packages out there that use a
different syntax.
I've been thinking about converting the LSM system into a
database-driven system that happens to output in LSM and HTML formats
... 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".
There's an additional advantage to displaying Entered-date using ctime
output: sometimes, we may edit an LSM file at two points during the
day (for example, some developers have been known to release two
versions of a program at different times during a single day.) Using
ctime format would include the time, so you not only know the DATE an
entry was updated, but the TIME.
I think FDUPDATE would have a much easier time reading & comparing
that output, too.
I'm really stuck on version numbers, though, since not everyone uses
the same format for how to assign the Version label. For example, I
usually use the simple labels "1.2", "3.1", ... but sometimes "3.1a"
if all I've added is a translation file. But some developers often
omits version number altogether, so I fake it when updating the LSM
file by using an encoded date (for example, "Version: 21jun2007".)
I suppose one "middle ground" method to know when to apply a
supposedly-updated package is when the Entered-date is NEWER and the
Version is DIFFERENT from what's installed. I suppose (when in doubt)
you would apply a supposedly-updated package if *both* Entered-date
and Version differ from what's installed. That probably only happens
when there's an update. Probably.
Mateusz and I have been discussing file formats and the update server.
Here are a few thoughts:
For the file format:
I'd really prefer to pass back an XML file. It's easily extensible to
suit many needs here. In the simplest case to identify the package
title, version, and LSM entered-date, we would have:
<pkglist>
<pkginf>
<title id="CHOICE" />
<version id="4.4" />
<entereddate id="2003-09-20" />
</pkginf>
</pkglist>
Obviously, there would be multiple <pkginf> sections, one for each package.
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:
<pkglist>
<pkginf>
<title id="CHOICE" />
<version id="4.4" />
<entereddate id="2003-09-20" />
<pkg id="choic44x.zip" />
<spkg id="choic44s.zip" />
</pkginf>
</pkglist>
For the server:
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/updates/
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/
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
So to do an update, the FDUPDATE program would just fetch
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/updates/base.lst
for the list of what updates to get for the "base" disk set. FDUPDATE
would crawl through the "base.lst" file, compare the Entered-date and
Version for each package against what's already installed. If it needs
to update a package, FDUPDATE downloads the pkg and spkg (as given in
the "lst" file) from
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/updates/pkgs/
and
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/updates/spkgs/
and installs them using FDPKG. Repeat for each disk set that is installed.
-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
