Line 1... |
Line 1... |
1 |
|
1 |
|
- |
|
2 |
%h*** SVARDOS PACKAGE FORMAT ***
|
- |
|
3 |
|
2 |
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
|
3 |
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
|
4 |
by the SvarDOS package manager.
|
6 |
by the SvarDOS package manager.
|
5 |
|
7 |
|
6 |
|
8 |
|
Line 9... |
Line 11... |
9 |
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
|
10 |
(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
|
11 |
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
|
12 |
'_'. 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
|
13 |
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
|
14 |
.SVP ("SvarDOS Package") extension.
|
16 |
.svp ("SvarDOS Package") extension.
|
15 |
|
17 |
|
16 |
|
18 |
|
17 |
%hPackage files
|
19 |
%hPackage files
|
18 |
|
20 |
|
19 |
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
|
20 |
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
|
21 |
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
|
22 |
supported, and in the public domain.
|
24 |
supported, and in the public domain.
|
23 |
|
25 |
|
24 |
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
|
25 |
package for a program named EXAMPLE using info-zip:
|
27 |
package for a program named EXAMPLE labelled as version "1.2.34" using
|
- |
|
28 |
info-zip's zip:
|
26 |
|
29 |
|
27 |
zip -9rkDX EXAMPLE.SVP subdir1 subdir2 ... subdirN
|
30 |
zip -9rkDX example-1.2.34.svp subdir1 subdir2 ... subdirN
|
28 |
|
31 |
|
29 |
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:
|
30 |
|
33 |
|
31 |
7za a -mm=deflate -mx=9 -tzip EXAMPLE.SVP subdir1 subdir2 ... subdirN
|
34 |
7za a -mm=deflate -mx=9 -tzip example-1.2.34.svp subdir1 subdir2 ... subdirN
|
- |
|
35 |
|
- |
|
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
|
- |
|
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.
|
32 |
|
40 |
|
33 |
|
41 |
|
34 |
%hPackage directory structure
|
42 |
%hPackage directory structure
|
35 |
|
43 |
|
36 |
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.
|
Line 112... |
Line 120... |
112 |
|
120 |
|
113 |
%hSources
|
121 |
%hSources
|
114 |
|
122 |
|
115 |
When a packaged software has its sources available, then it is recommended to
|
123 |
When a packaged software has its sources available, then it is recommended to
|
116 |
archive also them. To that effect, put the sources into a ZIP archive that has
|
124 |
archive also them. To that effect, put the sources into a ZIP archive that has
|
117 |
the same filename as the package, but a *.ZIP extension (as opposed to the
|
125 |
the same filename as the package, but a *.zip extension (as opposed to the
|
118 |
*.SVP extension of the proper package). The result would be that the packaged
|
126 |
*.svp extension of the proper package). The result would be that the packaged
|
119 |
software would be distributed within two files. Example for FDISK:
|
127 |
software would be distributed within two files. Example for FDISK:
|
120 |
|
128 |
|
121 |
FDISK.SVP <- binaries (ZIP archive following the SVP structure)
|
129 |
fdisk-1.55+2.svp <- binaries (ZIP archive following the SVP structure)
|
122 |
FDISK.ZIP <- sources (flat, unstructured ZIP archive)
|
130 |
fdisk-1.55+2.zip <- sources (flat, unstructured ZIP archive)
|
123 |
|
131 |
|
124 |
The ZIP file must obviously contain the source code that belongs to the exact
|
132 |
The ZIP file must obviously contain the source code that belongs to the exact
|
125 |
same version present in the SVP package.
|
133 |
same version present in the SVP package.
|