1 |
|
1 |
|
2 |
%h*** SVARDOS PACKAGE FORMAT ***
|
2 |
%h*** SVARDOS PACKAGE FORMAT ***
|
3 |
|
3 |
|
4 |
Package files provide an easy way to manage software on SvarDOS. These
|
4 |
Package files provide an easy way to manage software on SvarDOS. These
|
5 |
packages must adhere to a strict convention so they can be handled properly
|
5 |
packages must adhere to a strict convention so they can be handled properly
|
6 |
by the SvarDOS package manager.
|
6 |
by the SvarDOS package manager.
|
7 |
|
7 |
|
8 |
|
8 |
|
9 |
%hPackage filenames
|
9 |
%hPackage filenames
|
10 |
|
10 |
|
11 |
Packages names must follow some basic rules. They shall be max. 8 letters long
|
11 |
Packages names must follow some basic rules. They shall be max. 8 letters long
|
12 |
(but should not be too short either, since a 1 or 2-letters package name might
|
12 |
(but should not be too short either, since a 1 or 2-letters package name might
|
13 |
be confusing), and must not be composed of characters other than a-b, 0-9 and
|
13 |
be confusing), and must not be composed of characters other than a-b, 0-9 and
|
14 |
'_'. This for backward compatibility with short file names (8+3) and ISO 9660
|
14 |
'_'. This for backward compatibility with short file names (8+3) and ISO 9660
|
15 |
file systems (used on CDROMs). The package filename is always followed by the
|
15 |
file systems (used on CDROMs). The package filename is always followed by the
|
16 |
.svp ("SvarDOS Package") extension.
|
16 |
.svp ("SvarDOS Package") extension.
|
17 |
|
17 |
|
18 |
|
18 |
|
19 |
%hPackage files
|
19 |
%hPackage files
|
20 |
|
20 |
|
21 |
SvarDOS uses ZIP files as its package file format. This format has been chosen
|
21 |
SvarDOS uses ZIP files as its package file format. This format has been chosen
|
22 |
because ZIP files under DOS have become the de facto way to distribute
|
22 |
because ZIP files under DOS have become the de facto way to distribute
|
23 |
collections of files. Also, the ZIP file format is well documented, well
|
23 |
collections of files. Also, the ZIP file format is well documented, well
|
24 |
supported, and in the public domain.
|
24 |
supported, and in the public domain.
|
25 |
|
25 |
|
26 |
Here below is the recommended command line that can be used to create a
|
26 |
Here below is the recommended command line that can be used to create a
|
27 |
package for a program named EXAMPLE labelled as version "1.2.34" using
|
27 |
package for a program named EXAMPLE labelled as version "1.2.34" using
|
28 |
Info-ZIP's Zip:
|
28 |
Info-ZIP's Zip:
|
29 |
|
29 |
|
30 |
zip -9rkDX example-1.2.34.svp subdir1 subdir2 ... subdirN
|
30 |
zip -9rkDX example-1.2.34.svp subdir1 subdir2 ... subdirN
|
31 |
|
31 |
|
32 |
If you are using 7za to create your packages, then use this:
|
32 |
If you are using 7za to create your packages, then use this:
|
33 |
|
33 |
|
34 |
7za a -mm=deflate -mx=9 -tzip example-1.2.34.svp subdir1 subdir2 ... subdirN
|
34 |
7za a -mm=deflate -mx=9 -tzip example-1.2.34.svp subdir1 subdir2 ... subdirN
|
35 |
|
35 |
|
36 |
Note: The version in the filename is just an information for packagers so they
|
36 |
Note: The version in the filename is just an information for packagers so they
|
37 |
don't need to look into each package to know what version to expect there. In
|
37 |
don't need to look into each package to know what version to expect there. In
|
38 |
LSM versions you might have non-filesystem-compatible stuff like "10/11/11" so
|
38 |
LSM versions you might have non-filesystem-compatible stuff like "10/11/11" so
|
39 |
we don't want to enforce any kind of correlation.
|
39 |
we don't want to enforce any kind of correlation.
|
40 |
|
40 |
|
41 |
|
41 |
|
42 |
%hPackage directory structure
|
42 |
%hPackage directory structure
|
43 |
|
43 |
|
44 |
The directory structure of a package depends on the type of packages.
|
44 |
The directory structure of a package depends on the type of packages.
|
45 |
For "core" packages, we have this:
|
45 |
For "core" packages, we have this:
|
46 |
|
46 |
|
47 |
APPINFO Put the program's LSM file here
|
47 |
APPINFO Put the program's LSM file here
|
48 |
BIN Binaries, such as exe and com files
|
48 |
BIN Binaries, such as exe and com files
|
49 |
DOC\PKGNAME Package documentation
|
49 |
DOC\PKGNAME Package documentation
|
50 |
HELP Used ONLY by the "help" package
|
50 |
HELP Used ONLY by the "help" package
|
51 |
NLS\PKGNAME Localizations (NLS language files) of the package
|
51 |
NLS\PKGNAME Localizations (NLS language files) of the package
|
52 |
|
52 |
|
53 |
Non-core packages use a slightly different directory organization. For
|
53 |
Non-core packages use a slightly different directory organization. For
|
54 |
example, if we were to consider a package FOO, we might end up with the
|
54 |
example, if we were to consider a package FOO, we might end up with the
|
55 |
following structure:
|
55 |
following structure:
|
56 |
|
56 |
|
57 |
APPINFO\FOO.LSM Package meta file for the FOO program
|
57 |
APPINFO\FOO.LSM Package meta file for the FOO program
|
58 |
PROGS\FOO\FOO.EXE The program's executable
|
58 |
PROGS\FOO\FOO.EXE The program's executable
|
59 |
PROGS\FOO\FOO.TXT Some documentation
|
59 |
PROGS\FOO\FOO.TXT Some documentation
|
60 |
PROGS\FOO\FILE.DAT Data file used by the FOO program
|
60 |
PROGS\FOO\FILE.DAT Data file used by the FOO program
|
61 |
|
61 |
|
62 |
Note the PROGS directory above. This is the category to which the package
|
62 |
Note the PROGS directory above. This is the category to which the package
|
63 |
belongs. The package installer might change this directory at install time,
|
63 |
belongs. The package installer might change this directory at install time,
|
64 |
depending on the user's preferences. Possible categories are listed below:
|
64 |
depending on the user's preferences. Possible categories are listed below:
|
65 |
|
65 |
|
66 |
Category | Description
|
66 |
Category | Description
|
67 |
DEVEL | Development tools (mostly compilers)
|
67 |
DEVEL | Development tools (mostly compilers)
|
68 |
DRIVERS | Drivers
|
68 |
DRIVERS | Drivers
|
69 |
GAMES | Games
|
69 |
GAMES | Games
|
70 |
PROGS | User programs, tools...
|
70 |
PROGS | User programs, tools...
|
71 |
|
71 |
|
72 |
Note: "DOC", "NLS", "BIN" and "HELP" directories are strictly reserved to
|
72 |
Note: "DOC", "NLS", "BIN" and "HELP" directories are strictly reserved to
|
73 |
CORE packages.
|
73 |
CORE packages.
|
74 |
|
74 |
|
75 |
|
75 |
|
76 |
%hLSM meta-data files
|
76 |
%hLSM meta-data files
|
77 |
|
77 |
|
78 |
Every package MUST contain an LSM file in its "APPINFO" directory. This LSM
|
78 |
Every package MUST contain an LSM file in its "APPINFO" directory. This LSM
|
79 |
file is a text file that contains basic information about the package. Its
|
79 |
file is a text file that contains basic information about the package. Its
|
80 |
format is very simple, it must contain at least two lines:
|
80 |
format is very simple, it must contain at least two lines:
|
81 |
|
81 |
|
82 |
version: x.y.z
|
82 |
version: x.y.z
|
83 |
description: package description
|
83 |
description: package description
|
84 |
|
84 |
|
85 |
It may optionally contain also a line describing hardware requirements of the
|
85 |
It may optionally contain also a line describing hardware requirements of the
|
86 |
package, such as:
|
86 |
package, such as:
|
87 |
|
87 |
|
88 |
hwreq: 286 fpu cga hgc
|
88 |
hwreq: 286 fpu cga hgc
|
89 |
|
89 |
|
90 |
The "hwreq" line contains a space-separated list of tokens that represent
|
90 |
The "hwreq" line contains a space-separated list of tokens that represent
|
91 |
hardware requirements. Following tokens are possible.
|
91 |
hardware requirements. Following tokens are possible.
|
92 |
|
92 |
|
93 |
CPU family : 8086 186 286 386 486 586
|
93 |
CPU family : 8086 186 286 386 486 586
|
94 |
CPU features : fpu
|
94 |
CPU features : fpu
|
95 |
Graphic cards: mda cga ega mcga vga svga hgc
|
95 |
Graphic cards: mda cga ega mcga vga svga
|
96 |
|
96 |
|
97 |
Any other lines are ignored by the SvarDOS package manager.
|
97 |
Any other lines are ignored by the SvarDOS package manager.
|
98 |
|
98 |
|
99 |
|
99 |
|
100 |
%hPackage versions
|
100 |
%hPackage versions
|
101 |
|
101 |
|
102 |
The version present in the LSM file is meant to reflect the version of the
|
102 |
The version present in the LSM file is meant to reflect the version of the
|
103 |
packaged software, but it may happen that a package needs to be changed to
|
103 |
packaged software, but it may happen that a package needs to be changed to
|
104 |
fix a strictly packaging-related issue (for example a forgotten documentation
|
104 |
fix a strictly packaging-related issue (for example a forgotten documentation
|
105 |
file or a recompilation of the binary using a better set of flags...). In such
|
105 |
file or a recompilation of the binary using a better set of flags...). In such
|
106 |
case, the version of the software does not change, but the version of the
|
106 |
case, the version of the software does not change, but the version of the
|
107 |
package itself needs to change so users know something changed. That's where
|
107 |
package itself needs to change so users know something changed. That's where
|
108 |
"SvarDOS revisions" come in. A version string is basically following such
|
108 |
"SvarDOS revisions" come in. A version string is basically following such
|
109 |
format:
|
109 |
format:
|
110 |
|
110 |
|
111 |
UPSTREAM_VER[+SVARREV]
|
111 |
UPSTREAM_VER[+SVARREV]
|
112 |
|
112 |
|
113 |
UPSTREAM_VER is the exact version string advertised by the software. It may
|
113 |
UPSTREAM_VER is the exact version string advertised by the software. It may
|
114 |
be pretty much anything. This upstream version may be optionally followed by a
|
114 |
be pretty much anything. This upstream version may be optionally followed by a
|
115 |
plus sign and the SvarDOS revision. In the event that the upstream version
|
115 |
plus sign and the SvarDOS revision. In the event that the upstream version
|
116 |
already contains a plus sign, then SvarDOS revision is delimited with a tilde.
|
116 |
already contains a plus sign, then SvarDOS revision is delimited with a tilde.
|
117 |
|
117 |
|
118 |
The SvarDOS revision starts at 0 and increments by 1 each time that the given
|
118 |
The SvarDOS revision starts at 0 and increments by 1 each time that the given
|
119 |
upstream revision is repackaged. The SvarDOS revision restarts whenever the
|
119 |
upstream revision is repackaged. The SvarDOS revision restarts whenever the
|
120 |
upstream version changes. The SvarDOS revision of 0 is always hidden.
|
120 |
upstream version changes. The SvarDOS revision of 0 is always hidden.
|
121 |
|
121 |
|
122 |
Examples:
|
122 |
Examples:
|
123 |
|
123 |
|
124 |
FDISK 1.54 <- originally packaged version
|
124 |
FDISK 1.54 <- originally packaged version
|
125 |
FDISK 1.54+1 <- package has been changed, but not the upstream version
|
125 |
FDISK 1.54+1 <- package has been changed, but not the upstream version
|
126 |
FDISK 1.55 <- upstream version increased, so SvarDOS rev restarts
|
126 |
FDISK 1.55 <- upstream version increased, so SvarDOS rev restarts
|
127 |
FDISK 1.55+1 <- new version of the package, but still contains FDISK 1.55
|
127 |
FDISK 1.55+1 <- new version of the package, but still contains FDISK 1.55
|
128 |
FDISK 1.55+2 <- another new version of the package, etc
|
128 |
FDISK 1.55+2 <- another new version of the package, etc
|
129 |
|
129 |
|
130 |
The entire version string of a package must never exceed 16 characters.
|
130 |
The entire version string of a package must never exceed 16 characters.
|
131 |
|
131 |
|
132 |
|
132 |
|
133 |
%hSources
|
133 |
%hSources
|
134 |
|
134 |
|
135 |
When a packaged software has its sources available, then it is recommended to
|
135 |
When a packaged software has its sources available, then it is recommended to
|
136 |
archive also them. To that effect, put the sources into a ZIP archive that has
|
136 |
archive also them. To that effect, put the sources into a ZIP archive that has
|
137 |
the same filename as the package, but a *.zip extension (as opposed to the
|
137 |
the same filename as the package, but a *.zip extension (as opposed to the
|
138 |
*.svp extension of the proper package). The result would be that the packaged
|
138 |
*.svp extension of the proper package). The result would be that the packaged
|
139 |
software would be distributed within two files. Example for FDISK:
|
139 |
software would be distributed within two files. Example for FDISK:
|
140 |
|
140 |
|
141 |
fdisk-1.55+2.svp <- binaries (ZIP archive following the SVP structure)
|
141 |
fdisk-1.55+2.svp <- binaries (ZIP archive following the SVP structure)
|
142 |
fdisk-1.55+2.zip <- sources (flat, unstructured ZIP archive)
|
142 |
fdisk-1.55+2.zip <- sources (flat, unstructured ZIP archive)
|
143 |
|
143 |
|
144 |
The ZIP file must obviously contain the source code that belongs to the exact
|
144 |
The ZIP file must obviously contain the source code that belongs to the exact
|
145 |
same version present in the SVP package.
|
145 |
same version present in the SVP package.
|
146 |
|
146 |
|