WebSVN – SvarDOS – Diff – /website/tech/pkgformat.txt


Package files provide an easy way to manage software on svarDOS.
 
 
*** Package filenames ***
 
Packages names must follow some basic rules. They shall be max. 8 letters long (but should not be too short either, since a 1 or 2-letters package name might be confusing), and must not be composed of characters other than a-b, 0-9 and '_'. This for backward compatibility with short file names (8+3) and ISO 9660 file systems (used on CDROMs). The package filename is always followed by the .ZIP extension.
 
 
*** Package files ***
 
Svarog386 uses ZIP files as its package file format. This format has been chosen because ZIP files under DOS have become the de facto way to distribute collections of files. Also, the ZIP file format is well documented, well supported, and in the public domain.
 
Here below is the RECOMENDED command line that can be used to create a package for a program named EXAMPLE using info-zip:
 
  ZIP -9 -r -k EXAMPLE.ZIP subdir1 subdir2 ... subdirN
 
If you are using 7za to create your packages, then use this:
 
  7za a -mm=deflate -mx=9 -tzip EXAMPLE.ZIP subdir1 subdir2 ... subdirN
 
Note, that 7za allows to use different compression algorithms. The Svarog386 package manager (FDNPKG) supports two compression methods: Deflate and LZMA. Usually LZMA provides better compression than Deflate, however it is not recommended for general use because LZMA decompression requires much more memory than Deflate. LZMA decompression needs about 24MiB of memory, which is more than the total available memory on most DOS systems. LZMA might be used for specific packages that assume high-end systems (for example: 3D games, etc). In any case, it's always safer to stick with Deflate.
 
Nevertheless, if you wish to create a package using LZMA, use this:
 
  7za a -mm=lzma -tzip EXAMPLE.ZIP subdir1 subdir2 ... subdirN
 
 
*** Package directory structure ***
 
A package archive includes both binary and source code. The installer can choose to not unpack sources at install time.
 
The directory structure of a package depends on the type of packages. For "core" packages, we have this:
 
  APPINFO            Put the program's LSM file here
  BIN                Binaries, such as exe and com files
  DOC\%PKGNAME%      Package documentation
  HELP               The help files
  NLS\%PKGNAME%      Localizations (NLS language files) of the package
  SOURCE\%PKGNAME%   The complete source code
 
Non-core packages use a slightly different directory organization. For example, if we were to consider a package FOO, we might end up with the following structure:
 
  APPINFO\FOO.LSM    Package meta file for the FOO program
  PROGS\FOO\FOO.EXE  The program's executable
  PROGS\FOO\FOO.TXT  Some documentation
  PROGS\FOO\FILE.DAT Data file used by the FOO program
  LINKS\FOO.BAT      A "Link" file, see the "links" section for details
  SOURCE\FOO\*       here would be stored all foo's source files
 
Note the 'PROGS' directory above. This is a category to which the package belong. The package installer might change this directory at install time, depending on the user's preferences. Possible categories are listed below:
 
Category | Description
DEVEL    | Development tools (mostly compilers)
DRIVERS  | Drivers
GAMES    | Games
PROGS    | User programs, tools...
 
Note: "DOC", "NLS", "BIN" and "HELP" directories are strictly reserved to "core" packages.
 
 
*** Links ***
 
Many utilities are meant to be used from the command line to work on files. Such tools are often expected to be somewhere in the %PATH%, so one do not need to switch to the directory where the said utility is stored to use it. A good example of such tools are archivers (like zip, unrar...), but there are others, too. For such tools, the package format provides a "linking" provision. A package that wishes to put one or more of its executable in the %PATH%, will have to contain a LINKS directory, and in this directory a batch file for every executable that needs to be linked to %PATH%. The batch file must contain ONLY the path and filename to the target executable (as stored in the zip package). During installation, the package manager will substitute these batch files with proper content.
 

Subversion Repositories SvarDOS

(root)/website/tech/pkgformat.txt – Rev 3 → 172

Rev 3		Rev 172
1	`Package files provide an easy way to manage software on Svarog386.`	1	`Package files provide an easy way to manage software on svarDOS.`
2		2
3		3
4	`* Package filenames *`	4	`* Package filenames *`
5		5
6	`Packages names must follow some basic rules. They shall be max. 8 letters long (but should not be too short either, since a 1 or 2-letters package name might be confusing), and must not be composed of characters other than a-b, 0-9 and '_'. This for backward compatibility with short file names (8+3) and ISO 9660 file systems (used on CDROMs). The package filename is always followed by the .ZIP extension.`	6	`Packages names must follow some basic rules. They shall be max. 8 letters long (but should not be too short either, since a 1 or 2-letters package name might be confusing), and must not be composed of characters other than a-b, 0-9 and '_'. This for backward compatibility with short file names (8+3) and ISO 9660 file systems (used on CDROMs). The package filename is always followed by the .ZIP extension.`
7		7
8		8
9	`* Package files *`	9	`* Package files *`
10		10
11	`Svarog386 uses ZIP files as its package file format. This format has been chosen because ZIP files under DOS have become the de facto way to distribute collections of files. Also, the ZIP file format is well documented, well supported, and in the public domain.`	11	`Svarog386 uses ZIP files as its package file format. This format has been chosen because ZIP files under DOS have become the de facto way to distribute collections of files. Also, the ZIP file format is well documented, well supported, and in the public domain.`
12		12
13	`Here below is the RECOMENDED command line that can be used to create a package for a program named EXAMPLE using info-zip:`	13	`Here below is the RECOMENDED command line that can be used to create a package for a program named EXAMPLE using info-zip:`
14		14
15	`ZIP −9 -r -k EXAMPLE.ZIP subdir1 subdir2 ... subdirN`	15	`ZIP -9 -r -k EXAMPLE.ZIP subdir1 subdir2 ... subdirN`
16		16
17	`If you are using 7za to create your packages, then use this:`	17	`If you are using 7za to create your packages, then use this:`
18		18
19	`7za a -mm=deflate -mx=9 -tzip EXAMPLE.ZIP subdir1 subdir2 ... subdirN`	19	`7za a -mm=deflate -mx=9 -tzip EXAMPLE.ZIP subdir1 subdir2 ... subdirN`
20		20
21	Note, that 7za allows to use different compression algorithms. The Svarog386 package manager (FDNPKG) supports two compression methods: Deflate and LZMA. Usually LZMA provides better compression than Deflate, however it is not recommended for general use because LZMA decompression requires much more memory than Deflate. LZMA decompression needs about 24MiB of memory, which is more than the total available memory on most DOS systems. LZMA might be used for specific packages that assume high-end systems (for example: 3D games, etc). In any case, it's always safer to stick with Deflate.	21	Note, that 7za allows to use different compression algorithms. The Svarog386 package manager (FDNPKG) supports two compression methods: Deflate and LZMA. Usually LZMA provides better compression than Deflate, however it is not recommended for general use because LZMA decompression requires much more memory than Deflate. LZMA decompression needs about 24MiB of memory, which is more than the total available memory on most DOS systems. LZMA might be used for specific packages that assume high-end systems (for example: 3D games, etc). In any case, it's always safer to stick with Deflate.
22		22
23	`Nevertheless, if you wish to create a package using LZMA, use this:`	23	`Nevertheless, if you wish to create a package using LZMA, use this:`
24		24
25	`7za a -mm=lzma -tzip EXAMPLE.ZIP subdir1 subdir2 ... subdirN`	25	`7za a -mm=lzma -tzip EXAMPLE.ZIP subdir1 subdir2 ... subdirN`
26		26
27		27
28	`* Package directory structure *`	28	`* Package directory structure *`
29		29
30	`A package archive includes both binary and source code. The installer can choose to not unpack sources at install time.`	30	`A package archive includes both binary and source code. The installer can choose to not unpack sources at install time.`
31		31
32	`The directory structure of a package depends on the type of packages. For "core" packages, we have this:`	32	`The directory structure of a package depends on the type of packages. For "core" packages, we have this:`
33		33
34	`APPINFO Put the program's LSM file here`	34	`APPINFO Put the program's LSM file here`
35	`BIN Binaries, such as exe and com files`	35	`BIN Binaries, such as exe and com files`
36	`DOC\%PKGNAME% Package documentation`	36	`DOC\%PKGNAME% Package documentation`
37	`HELP The help files`	37	`HELP The help files`
38	`NLS\%PKGNAME% Localizations (NLS language files) of the package`	38	`NLS\%PKGNAME% Localizations (NLS language files) of the package`
39	`SOURCE\%PKGNAME% The complete source code`	39	`SOURCE\%PKGNAME% The complete source code`
40		40
41	`Non-core packages use a slightly different directory organization. For example, if we were to consider a package FOO, we might end up with the following structure:`	41	`Non-core packages use a slightly different directory organization. For example, if we were to consider a package FOO, we might end up with the following structure:`
42		42
43	`APPINFO\FOO.LSM Package meta file for the FOO program`	43	`APPINFO\FOO.LSM Package meta file for the FOO program`
44	`PROGS\FOO\FOO.EXE The program's executable`	44	`PROGS\FOO\FOO.EXE The program's executable`
45	`PROGS\FOO\FOO.TXT Some documentation`	45	`PROGS\FOO\FOO.TXT Some documentation`
46	`PROGS\FOO\FILE.DAT Data file used by the FOO program`	46	`PROGS\FOO\FILE.DAT Data file used by the FOO program`
47	`LINKS\FOO.BAT A "Link" file, see the "links" section for details`	47	`LINKS\FOO.BAT A "Link" file, see the "links" section for details`
48	`SOURCE\FOO\* here would be stored all foo's source files`	48	`SOURCE\FOO\* here would be stored all foo's source files`
49		49
50	`Note the 'PROGS' directory above. This is a category to which the package belong. The package installer might change this directory at install time, depending on the user's preferences. Possible categories are listed below:`	50	`Note the 'PROGS' directory above. This is a category to which the package belong. The package installer might change this directory at install time, depending on the user's preferences. Possible categories are listed below:`
51		51
52	`Category \| Description`	52	`Category \| Description`
53	`DEVEL \| Development tools (mostly compilers)`	53	`DEVEL \| Development tools (mostly compilers)`
54	`DRIVERS \| Drivers`	54	`DRIVERS \| Drivers`
55	`GAMES \| Games`	55	`GAMES \| Games`
56	`PROGS \| User programs, tools...`	56	`PROGS \| User programs, tools...`
57		57
58	`Note: "DOC", "NLS", "BIN" and "HELP" directories are strictly reserved to "core" packages.`	58	`Note: "DOC", "NLS", "BIN" and "HELP" directories are strictly reserved to "core" packages.`
59		59
60		60
61	`* Links *`	61	`* Links *`
62		62
63	Many utilities are meant to be used from the command line to work on files. Such tools are often expected to be somewhere in the %PATH%, so one do not need to switch to the directory where the said utility is stored to use it. A good example of such tools are archivers (like zip, unrar...), but there are others, too. For such tools, the package format provides a "linking" provision. A package that wishes to put one or more of its executable in the %PATH%, will have to contain a LINKS directory, and in this directory a batch file for every executable that needs to be linked to %PATH%. The batch file must contain ONLY the path and filename to the target executable (as stored in the zip package). During installation, the package manager will substitute these batch files with proper content.	63	Many utilities are meant to be used from the command line to work on files. Such tools are often expected to be somewhere in the %PATH%, so one do not need to switch to the directory where the said utility is stored to use it. A good example of such tools are archivers (like zip, unrar...), but there are others, too. For such tools, the package format provides a "linking" provision. A package that wishes to put one or more of its executable in the %PATH%, will have to contain a LINKS directory, and in this directory a batch file for every executable that needs to be linked to %PATH%. The batch file must contain ONLY the path and filename to the target executable (as stored in the zip package). During installation, the package manager will substitute these batch files with proper content.
64		64