2007/12/2, Jim Hall <[EMAIL PROTECTED]>:
> There is an important difference. What I put in the general archive on
> ibiblio is a mirror of other people's work. For most programs, they
> already have another primary location, and (license permitting) I'm
> just putting it on ibiblio so that it has at least a 2nd place to live
> (for example, in case the original site goes down or otherwise becomes
> unavailable.) Users should still be able to download the original
> program in its original archive from ibiblio, AND IT SHOULD BE
> IDENTICAL TO WHAT WAS ORIGINALLY RELEASED BY THE AUTHOR/MAINTAINER.
But it is not even true for the packages in the distributions,
compared to the ones created by us (for which I'm grateful, they are
> Else, it would confuse which was the version that the author had
> actually released. That's why when I reply to announcements about new
> program versions on this list, I consistently say I "mirrored your
> release on ibiblio", and why I no longer convert rar files to zip
> It would also mean the general archive on ibiblio was no longer a
> mirror site - and it needs to remain a mirror site.
May I then suggest the use of the mapping file that I mentioned in the
In fact, the example you mentioned, 4DOS, will probably not have an
Perhaps it could be a good idea that besides any ZIP (untouched) there
would be a file with the same name, but some extension, like LSM or
another, that would contain all those extra info needed for the
packager: the version or date to compare, the mapping of files onto
the pkg structure, and other useful info (such as post-install script
that I mentioned too). Actually, this info file could be the XML that
Jim suggested, a quite extensible idea (hopefully XMLs are easy to
read in C?).
Thus, a ZIP that does NOT have such file could be extracted asking the
user for a directory, whereas if such info file exists, it is clear
what is to be done.
True that it's some quite extra work to be done (specially for source packages).
> Mateusz & I just had a brief off-list discussion where I suggested we
> may want to change how FDPKG manages packages. One thing we may want
> to do is have all pkg files have a PKG or FDP ("FreeDOS Package")
> extension, rather than keep the zip extension, even though the pkg
> file is just a zip file with a particular directory structure.
> Changing the extension would be a good way to implicitly declare that
> the pkg file is not the original release zip file (4dos759.zip &
> 4dos759.fdp, for example.)
Oops, I hadn't read this when I wrote my previous mail. Needless to
say, I like the idea ;-)
> It might be a good/interesting idea, though, to add an option to
> FDUPDATE to tell it to read/unzip the packages in-place (i.e. assume a
> local repo) rather than wget them to a local cache. Obviously, that
> works well when the repo is local, but not so well when the repo is on
> a web server somewhere.
You're talking (I guess?) as some type of "repository type", that
could be either internet or local. Perhaps the "address" could give
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