Hello,
I am going to give a bunch of ideas, I hope any of those is of some use.
2007/12/2, Jim Hall <[EMAIL PROTECTED]>:
> > > One more thing: I think the pkgs and spkgs for the update server
> > > should be assumed to be different than the zip files that we upload to
> > > ibiblio. A pkg and spkg have a particular meaning; they contain a
> > > particular directory structure.
> >
> > You are right, but it would be good if we could move towards a point
> > where all files have that directory structure. Otherwise, it will be
> > the exception, not the rule, that a downloaded zip file can be used
> > for updating. For all "normal" files, people now are forced to unzip
> > to a temp directory and spend time to sort the files to put them in
> > the right directories in their installed freedos.
>
> It's not realistic to assume we will be able to have *every* zip file
> on the ibiblio archive to use the FreeDOS pkg directory structure.
> There are a few problems here:
>
> 1. Not all developers care about FreeDOS pkg structure. And it would
> be inappropriate of me to re-zip their release into a FreeDOS
> pkg-compatible structure. (It would be ok to create a pkg to put on
> the update server, but it is not ok to re-zip someone else's work
> before putting it in the general archive.) Also note that sometimes we
> put zip files on ibiblio that cannot be included on the FreeDOS
> distribution because they are not free for all, but are useful for
> some. The license for these "non-free" programs may prohibit
> repackaging.
As I see it, the fact that some DOS software is mirrored at ibiblio's
FreeDOS repository is a privilege, not a nice present.
Thus, it could be an idea that there is some kind of "FreeDOS logotype
test" (LOL ;-)) meaning that some programs have passed the minimum
requirements of:
- An LSM is submitted, so that the software is fully described
- It fully follows the pkg structure.
At certain time I even thought of a second approach to this problem: a
FreeDOS package to be a ZIP file with another extension (say FPF or
FreeDOS Package File) matching certain conditions, such as:
- it follows the pkg structure
- there exists the appinfo/XXX.LSM file
I thought of the second because the programmer could encode in that
LSM the condition to run certain Post-Install script, that would be
run after the package is installed. The "extended LSM" could host
other information, that we might not exploit at this moment, but maybe
in the future. Things like: dependencies, path to executable, path to
a HTML-Help file (for automatic Help update), etc.
Then there's the decission whether the FreeDOS package would be able
to deal with these special FPF files (and deal with the versioning
stuff, post-install script, maybe dependencies), and for standard ZIP
packages, well, just the basic ("there exists XXX.ZIP with date YYY,
newer than current XXX.LSM, install?").
> 3. We may (at some later date) choose to change the FreeDOS pkg
> directory layout. As of today, no suggestions to do this have been
> made, but a year from now it's possible that we may want to change it.
> I don't want to re-zip everything on ibiblio to meet the new pkg
> standard.
Perhaps it is the moment to see if the pkg structure needs a review or
not. We could discuss about it, and settle certain "FreeDOS directory
structure 1.0", so that programs are based on it.
A clever idea that Microsoft does (for example, to allow locale in
filenames, "C:\Program Files" is, in my system, "C:\Archivos de
Programa\") IIRC is to use a kind of "location variable", so that for
example, %10 would be Program Files, %11 would be Windows folder, etc.
It would be certainly quite a lot of more work, but it could be that
the ZIP (or FPF) does NOT have directories, but has instead a mapping
file:
\DISKCOPY.001 => %12\DISKCOPY.EXE
(and in turn, %12 could be standarised to C:\FREEDOS\BIN by the
packager program).
> 4. Others who "roll their own distro" for themselves or for a distro
> they make available to others may not want to use our pkg directory
> layout, but instead go with something slightly different.
and don't they have their own package program too (as in Linux)?
> > > But the FDUPDATE program will be downloading these files using
> > > wget to a DOS filesystem.
> >
> > Suggestion: wget -O choicex.zip http://foo/bar/choice-4.4-binary.zip
> >
> > This also makes sure that you have a "static" name of the
> > downloaded file (does not contain a version number) and also
> > a "readable" name (does contain the full name "choice") after
> > the download and a readable name including a readable version
> > number on the server :-).
> >
> > Remember that it is useful if people can find a package with
> > google. Bonnie probably has a lot of experience with this
> > when she tried to find new downloads of various packages...
> > She would not have found a "dkcp0815.zip" when looking for
> > "freedos diskcopy".
>
> Your suggestion works well when the package title is 7 characters or
> less. But you give an example of a package title that is 8 characters
> (DISKCOPY). Also DISKCOMP, CUTEMOUSE, GRAFTABL, FASTHELP, FDSHIELD,
> FDXMS286, GRAPHICS, LBACACHE, UNFORMAT ... all from the Base list. And
> FDUPDATE. :-) Also be aware of potential confusion between HIMEM and
> HIMEMX, which are both different packages.
>
> But since we don't seem to have pkg dependencies in FreeDOS pkgs, I
> suppose there is no reason for FDUPDATE to save the pkg to a
> recognizable filename. After all, it's only downloading into its local
> cache, and probably can be safely deleted from the cache after all
> updates are applied. So FDUPDATE could maintain an internal counter of
> files downloaded, and do this:
>
> wget -O 00000001.ZIP http://..../1.1/updates/pkgs/base/choic44x.zip
>
>
> You have room for 99,999,999 packages downloaded at once before you
> run out of (numerical) namespace. Not likely to reach this, but
> FDUPDATE could always switch to an alpha-numeric namespace if we think
> this will be a limitation. :-)
Good idea!
Aitor
-------------------------------------------------------------------------
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
