home *** CD-ROM | disk | FTP | other *** search
- 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