to bring my off-list thoughts about the updater on the list:
I agree that using LSMs would be better than using a flat
directory of zips. The version numbers are not machine
comparable, but LSMs are machine readable. As it is highly
unlikely that the update server has an OLDER version than
the user, I think it is enough to update as soon as the
user and the server use a DIFFERENT version number of some
Another issue is that LSMs do not yet contain exact file
names for downloads. This is intentional, as giving a
more "front page" URL allows the user to manually look
if there is an even newer version than the one mentioned
in the LSM already. In addition, many non-core packages
simply have no ZIP with freedos installer / fdpkg compatible
package / directory structure on their homepage, so the
main use of LSM at the moment is helping the user when he
does manual updates of packages.
Of course the update server could have some sort of data
file which has pointers to exact download URLs. Somebody
will also have to make well-structured zips, but as soon
as those are available, I would NOT put them on the update
server. Instead, I would put them on ibiblio, where we
already do keep copies of all packages.
Rugxulo, Fritz and others have provided a big update of the
LSM collection already, so we already know about a big number
of updated packages and where to download them, even though
those downloads are often not in fdpkg compatible shape yet.
Everybody is welcome to help in making nicely shaped zips :-).
Note that if you turned LSM into "output of a database", then
it will be harder for you to receive zips with updated LSMs
from people like Fritz.
Using the LSM timestamp / entered-time in addition to the not
really machine readable version numbers is certainly an idea.
I would not want to force everybody to use some unified version
numbering scheme, so using timestamps is a good fallback. Plus,
as said "if version numbers DIFFER, then the server probably
has a newer version" :-).
> 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.
Agreed. In the latter case, you could prompt the user :-).
> On ibiblio, I could set up an "updates" subdirectory.
That is a nice idea, but I hope that it will only contain copies
of files which have been updated in their native ibiblio subdirectory
as well before... ;-)
> Under "updates" we could have a separate subdirectory to separate
> exe packages ("pkg") from src packages ("spkg"). For example:
Good idea. Maybe even separate per category (base, ...).
PS: LSM files are a classic, but certainly not the best choice
for everything. For example, LSM waste a lot of space on disk
when you install DOS on a filesystem with big clusters, as the
LSMs are small but many files.
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