Chip 2004 July/CMCD0704.ISO/Software/Complet/FreeDOS/fdbootcd.iso/FREEDOS/DOCS/DISTRIB.TXT

Text File | 2004-01-03 | 6KB | 123 lines

This document describes the layout and contents of packages.
The FreeDOS project uses the ZIP format for packaging its software.


***
Repackaging the original maintainers archives for use as packages
by the FreeDOS installer --- or --- Packages for a FreeDOS distribution

History, a question asked by Bernd Blaauw on the old Topica fd-dev list:

...
BB> For me, the problem is I cannot find a formal specification on how to
BB> repack packages.  A release package gets transformed in a "binary package"
BB> and a "source package", which each need some formal directory structure
BB> and rules of which files to include in which package.
...


Related documentation:

http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=Installing_FreeDOS/25
("What is the directory structure for the FreeDOS installer?")

http://fd-doc.sourceforge.net/mini/en/distrib.txt
("How to create a FreeDOS distribution, Mini-Howto")

http://fd-doc.sourceforge.net/howto/en/distrib.txt
("FreeDOS Distribution HOWTO")


Whenever creating new or updated packages, it is often helpful
to look at the layout of the current/previous packages and
use that as a guideline of what goes where.

However please note:
The following information is regarding packages included
within the distribution and I don't recommend maintainers
release standalone packages that follow it exactly; ie the
{program} component in directories should be ommitted and the
full license text should be included.  However, splitting
the packages into source & binary, with binary being subdivided
into at least DOC, NLS, other is a big help!

The layout of the binary packages is:
BIN\{program}.exe
// and any additional files required, e.g. BIN\FDISK.INI or BIN\KEY\*.key ...
DOC\{program}\
HELP\{program}.{lang}
NLS\
APPINFO\{program}.lsm

- All directories other than BIN are optional
 (technically bin is optional, but its a pointless package without an executable :)

-Each package is created to be installed relative to the main DOS
 directory selected at install time, so BIN will become C:\FDOS\BIN
 if C:\FDOS is the user selected location, or may be D:\BLAH\FDOS\B7\BIN
 if user installs to D:\BLAH\FDOS\B7.  Nothing should go into .\
 unless it is global to all packages; presently this is used only by
 two packages, GPLv2, which has COPYING - the GPL v2 license text,
 and SAMCFG, which includes sample & documented config.sys and autoexec.bat
 files.

-To reduce some space, packages [meant for inclusion with
 the distribution and not seperately] have a stub license file that
 points the user to COPYING or indicates the file should be replaced
 with full text if distributed seperately from the distribution.

-Within BIN should be the actual program executable and any
 additional files it requires for running, such as configuration files.
 If not already compressed, one may compact the exe with a program
 such as UPX or APACK (see their respective licenses for conditions
 of doing so), as long as --8086 or equivalent option is used!

-Within DOC\{program}\ subdirectory should be any files within the
 original archive's DOC, DOCS, or similar directory, otherwise
 anything that looks like useful user documentation (developer
 docs may also be added).

-Within HELP is one or more help files [one for each language],
 which unless included with the original archive means just
 HELP\{program}.EN is included.  If a help file for use by
 fasthelp is included, then it is used unmodified, otherwise
 a help file is created.  Depending on the program and included
 docs, this may be simply the README renamed (or possibly with
 some supplemental text added), a combination (possibly with
 formatting edits) of included docs, or simply the program's
 internal help, "BIN\{program}.exe /? > HELP\{program}.EN"

-NLS is optional unless the program includes text catalogs
 for one or more languages, these usually are in a NLS
 subdirectory of the original archive.

-And a copy of the LSM is placed in APPINFO, so user's can
easily see what version is included, who maintains it, and
where to check for updates.

For the source packages, place the contents of the original
archive into SOURCE\{program}\.  If the original archive is
split, then do this with the source variant and you are done,
otherwise remove any executables and anything else you feel
appropriate (i.e. duplicates that are in the binary
package already, but please don't remove items that aren't
otherwise available).  Usually I just remove the binary
files and leave it as the author/maintainer packaged it.

Once all the the packages have been created and the corresponding
installer data file (e.g. BASE.1 & BASE.END) are created,
run through the install and see which packages need correcting;
one will eventually forget to place some docs in a subdirectory
with the program's name, ie straight into DOC\ instead of
DOC\{program}\ or similar, which needs to be corrected.  Once
this is done then comes the fun part.  For a CD or large media
install, create a single zip with all the packages, this is
BASE1.ZIP, for smaller disk sizes, subdivide this into sets
that will fit on the disk, split BASE.1 into corresponding
sets, zip each one up, placing BASE.END with the last one;
this will be the files BASE1.ZIP, BASE2.ZIP, BASE3.ZIP, ...
for however many sets are required.  Be sure to retest
your small sets to insure you didn't forget any packages and
your BASE.1 splitup matches the actual zips.

Jeremy