Subversion Repositories SvarDOS

Rev

Rev 689 | Rev 893 | Go to most recent revision | Details | Compare with Previous | Last modification | View Log | RSS feed

Rev Author Line No. Line
286 mateuszvis 1
 
2
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
4
by the SvarDOS package manager.
5
 
6
 
7
%hPackage filenames
8
 
9
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
11
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
13
file systems (used on CDROMs). The package filename is always followed by the
689 mateusz.vi 14
.SVP ("SvarDOS Package") extension.
286 mateuszvis 15
 
16
 
17
%hPackage files
18
 
19
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
21
collections of files. Also, the ZIP file format is well documented, well
22
supported, and in the public domain.
23
 
24
Here below is the recommended command line that can be used to create a
25
package for a program named EXAMPLE using info-zip:
26
 
711 bttr 27
  zip -9rkDX EXAMPLE.SVP subdir1 subdir2 ... subdirN
286 mateuszvis 28
 
29
If you are using 7za to create your packages, then use this:
30
 
711 bttr 31
  7za a -mm=deflate -mx=9 -tzip EXAMPLE.SVP subdir1 subdir2 ... subdirN
286 mateuszvis 32
 
33
 
34
%hPackage directory structure
35
 
36
The directory structure of a package depends on the type of packages.
37
For "core" packages, we have this:
38
 
39
  APPINFO            Put the program's LSM file here
40
  BIN                Binaries, such as exe and com files
565 mateuszvis 41
  DOC\PKGNAME        Package documentation
286 mateuszvis 42
  HELP               Used ONLY by the "help" package
565 mateuszvis 43
  NLS\PKGNAME        Localizations (NLS language files) of the package
286 mateuszvis 44
 
45
Non-core packages use a slightly different directory organization. For
46
example, if we were to consider a package FOO, we might end up with the
47
following structure:
48
 
49
  APPINFO\FOO.LSM    Package meta file for the FOO program
50
  PROGS\FOO\FOO.EXE  The program's executable
51
  PROGS\FOO\FOO.TXT  Some documentation
52
  PROGS\FOO\FILE.DAT Data file used by the FOO program
53
 
685 bttr 54
Note the PROGS directory above. This is the category to which the package
55
belongs. The package installer might change this directory at install time,
286 mateuszvis 56
depending on the user's preferences. Possible categories are listed below:
57
 
58
Category | Description
59
DEVEL    | Development tools (mostly compilers)
60
DRIVERS  | Drivers
61
GAMES    | Games
62
PROGS    | User programs, tools...
63
 
64
Note: "DOC", "NLS", "BIN" and "HELP" directories are strictly reserved to
65
      CORE packages.
66
 
584 mateuszvis 67
 
286 mateuszvis 68
%hLSM meta-data files
69
 
70
Every package MUST contain an LSM file in its "APPINFO" directory. This LSM
71
file is a text file that contains basic information about the package. Its
72
format is very simple, it must contain at least two lines:
73
 
74
  version: x.y.z
75
  description: package description
76
 
77
Any other lines are ignored by the SvarDOS package manager.
584 mateuszvis 78
 
79
 
80
%hPackage versions
81
 
82
The version present in the LSM file is meant to reflect the version of the
83
packaged software, but it may happen that a package needs to be changed to
84
fix a strictly packaging-related issue (for example a forgotten documentation
85
file or a recompilation of the binary using a better set of flags...). In such
86
case, the version of the software does not change, but the version of the
621 mateuszvis 87
package itself needs to change so users know something changed. That's where
584 mateuszvis 88
"SvarDOS revisions" come in. A version string is basically following such
89
format:
90
 
91
  UPSTREAM_VER[+SVARREV]
92
 
93
UPSTREAM_VER is the exact version string advertised by the software. It may
94
be pretty much anything. This upstream version may be optionally followed by a
621 mateuszvis 95
plus sign and the SvarDOS revision. In the event that the upstream version
584 mateuszvis 96
already contains a plus sign, then SvarDOS revision is delimited with a tilde.
97
 
687 bttr 98
The SvarDOS revision starts at 0 and increments by 1 each time that the given
584 mateuszvis 99
upstream revision is repackaged. The SvarDOS revision restarts whenever the
100
upstream version changes. The SvarDOS revision of 0 is always hidden.
101
 
102
Examples:
103
 
104
FDISK 1.54      <- originally packaged version
105
FDISK 1.54+1    <- package has been changed, but not the upstream version
106
FDISK 1.55      <- upstream version increased, so SvarDOS rev restarts
107
FDISK 1.55+1    <- new version of the package, but still contains FDISK 1.55
108
FDISK 1.55+2    <- another new version of the package, etc
689 mateusz.vi 109
 
110
The entire version string of a package must never exceed 16 characters.
111
 
112
 
113
%hSources
114
 
115
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
117
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
119
software would be distributed within two files. Example for FDISK:
120
 
121
FDISK.SVP       <- binaries (ZIP archive following the SVP structure)
122
FDISK.ZIP       <- sources (flat, unstructured ZIP archive)
123
 
124
The ZIP file must obviously contain the source code that belongs to the exact
125
same version present in the SVP package.