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

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
> files.
> 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
previous mail?
In fact, the example you mentioned, 4DOS, will probably not have an
LSM launched.

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
the clue:


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

Reply via email to