Subversion Repositories SvarDOS

Rev

Rev 584 | Rev 645 | 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
14
.ZIP extension.
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
 
564 mateuszvis 27
  zip -9rkDX EXAMPLE.ZIP subdir1 subdir2 ... subdirN
286 mateuszvis 28
 
29
If you are using 7za to create your packages, then use this:
30
 
31
  7za a -mm=deflate -mx=9 -tzip EXAMPLE.ZIP subdir1 subdir2 ... subdirN
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
44
  SOURCE\PKGNAME     The source code (optional)
286 mateuszvis 45
 
46
Non-core packages use a slightly different directory organization. For
47
example, if we were to consider a package FOO, we might end up with the
48
following structure:
49
 
50
  APPINFO\FOO.LSM    Package meta file for the FOO program
51
  PROGS\FOO\FOO.EXE  The program's executable
52
  PROGS\FOO\FOO.TXT  Some documentation
53
  PROGS\FOO\FILE.DAT Data file used by the FOO program
54
  SOURCE\FOO\*       here would be stored the foo's source code (optional)
55
 
56
Note the 'PROGS' directory above. This is a category to which the package
57
belong. The package installer might change this directory at install time,
58
depending on the user's preferences. Possible categories are listed below:
59
 
60
Category | Description
61
DEVEL    | Development tools (mostly compilers)
62
DRIVERS  | Drivers
63
GAMES    | Games
64
PROGS    | User programs, tools...
65
 
66
Note: "DOC", "NLS", "BIN" and "HELP" directories are strictly reserved to
67
      CORE packages.
68
 
584 mateuszvis 69
 
286 mateuszvis 70
%hLSM meta-data files
71
 
72
Every package MUST contain an LSM file in its "APPINFO" directory. This LSM
73
file is a text file that contains basic information about the package. Its
74
format is very simple, it must contain at least two lines:
75
 
76
  version: x.y.z
77
  description: package description
78
 
79
Any other lines are ignored by the SvarDOS package manager.
584 mateuszvis 80
 
81
 
82
%hPackage versions
83
 
84
The version present in the LSM file is meant to reflect the version of the
85
packaged software, but it may happen that a package needs to be changed to
86
fix a strictly packaging-related issue (for example a forgotten documentation
87
file or a recompilation of the binary using a better set of flags...). In such
88
case, the version of the software does not change, but the version of the
621 mateuszvis 89
package itself needs to change so users know something changed. That's where
584 mateuszvis 90
"SvarDOS revisions" come in. A version string is basically following such
91
format:
92
 
93
  UPSTREAM_VER[+SVARREV]
94
 
95
UPSTREAM_VER is the exact version string advertised by the software. It may
96
be pretty much anything. This upstream version may be optionally followed by a
621 mateuszvis 97
plus sign and the SvarDOS revision. In the event that the upstream version
584 mateuszvis 98
already contains a plus sign, then SvarDOS revision is delimited with a tilde.
99
 
100
The SvarDOS revision starts at 0 and increments each time that the given
101
upstream revision is repackaged. The SvarDOS revision restarts whenever the
102
upstream version changes. The SvarDOS revision of 0 is always hidden.
103
 
104
Examples:
105
 
106
FDISK 1.54      <- originally packaged version
107
FDISK 1.54+1    <- package has been changed, but not the upstream version
108
FDISK 1.55      <- upstream version increased, so SvarDOS rev restarts
109
FDISK 1.55+1    <- new version of the package, but still contains FDISK 1.55
110
FDISK 1.55+2    <- another new version of the package, etc