By default, opsystem has two kinds of package types built-in: a binary and a source one.
:: binary ::
A binary package will always have a .opp extension (short for "opsystem package") and is comprised of 3 simple parts:
- A "marker", which contains information about what kind of package it is and helps separate its parts and check their integrity. The "marker" is just a one-line long identifier comprised of 6 fields. They are:
a. the protocol version and type that should be used to process the package (in this case, "1.0-bin")
b. the byte-count of the "header archive" (for separation purposes)
c. the md5sum of the "header archive" (for integrity checking)
d. the byte-count of the "binary archive" (for separation purposes)
e. the md5sum of the "binary archive" (for integrity checking)
f. the md5sum of values a-e, including the 4 spaces that help separate them
Here's an example of a valid "marker" (it should all fit on one line):
1.0-bin 321 96fed829939bb5cb24c36688e4318d97 174177 ba825e79ad323333f9a51a8ace57e6bc e26268e35a3dab7e5f595bfa68787021
- A "header archive", which contains information and scripts that are needed for processing and installation purposes, containing:
a. the package information file (pif), which contains the following information about the binary package:
Name: bash
Version: 2.05b
Release: 2
Architecture: i686
Depends: readline
Maintainer: Andrei Oprisan
Summary: The Bource Again SHell.
Description: This package contains the Bourne Again SHell (bash). This
Description: shell
Description: is compatible with the standard Unix shells and provides
Description: features above and
Description: beyond those of the traditional ones.
Note that although the description of the package is segmentated on many lines, with some lines having more words than others, the outcoming sumary will be:
This package contains the Bourne Again SHell (bash). This shell is compatible with the standard Unix shells and provides features above and beyond those of the traditional ones.
It must also be noted that the order in which the following lines are presented musn't necesarelly be that which is presented above. For example, we could have the "Name" field as the second to last line and some of the "Description" lines anywhere in the file; as long as they're there, opsystem will extract all the correct information.
b. the pre-install script (optional):
This script may be executed right before the package's binary archive is extracted in the root folder. It does not have to be executable (with the executable bit set), but as this will be treated as a shell script, it will need to have the string "#!/bin/sh" as the first line.
c. the post-install script (optional):
This script may be executed right after the package's binary archive is extracted in the root folder. It does not have to be executable (with the executable bit set), but as this will be treated as a shell script, it will need to have the string "#!/bin/sh" as the first line.
d. the pre-remove script (optional):
This script may be executed right before a package will be removed. It does not have to be executable (with the executable bit set), but as this will be treated as a shell script, it will need to have the string "#!/bin/sh" as the first line.
e. the post-remove script (optional):
This script may be executed right after a package will be removed. It does not have to be executable (with the executable bit set), but as this will be treated as a shell script, it will need to have the string "#!/bin/sh" as the first line.
It must be noted that the archive is comprised of at least one (the pif file) or more of the above files, and that when compressed, .tar.bz2 compression is used.
The binary archive, containing all the files that will be installed by the package, excluding the database entries (.tar.bz2 compressed).
:: source ::
A source package will always have a .sopp extension (short for "source opsystem package") and is comprised of 3 simple parts:
- A "marker", which contains information about what kind of package it is and helps separate its parts and check their integrity. The "marker" is just a one-line long identifier comprised of 6 fields. They are:
a. the protocol version and type that should be used to process the package (in this case, "1.0-src")
b. the byte-count of the "header archive" (for separation purposes)
c. the md5sum of the "header archive" (for integrity checking)
d. the byte-count of the "source archive" (for separation purposes)
e. the md5sum of the "source archive" (for integrity checking)
f. the md5sum of values a-e, including the 4 spaces that help separate them
Here's an example of a valid "marker" (it should all fit on one line):
1.0-src 321 96fed829939bb5cb24c36688e4318d97 174177 ba825e79ad323333f9a51a8ace57e6bc e26268e35a3dab7e5f595bfa68787021
- A "header archive", containing information and scripts that are needed for processing, compilation, and building purposes:
a. the list of build-time dependencies (builddep)automake autoconf>2.0 gcc<3.4 glibc bash-2.05
b. the build resource file
This file has all the required instructions needed to compile and "fakely" install the package.
A valid example is:
# name: bash
# version: 2.05b
# revision: 1
# architecture:i686
# :: this script is maintained by Andrei Oprisan
# we are in the package file's sources folder
# the variables: pkg_name
# pkg_version
# pkg_release
# are available
_patch_all () {
# all patches are in ../../final/
# to patch a patch file, run, for example:
# patch -Np1 -i ../../final/pachname.patch
patch -Np1 -i ../../final/bash-2.05b-gnu-fixes-2.patch
}
_configure () {
CFLAGS="$CFLAGS -march=`uname -m` -mcpu=`uname -m`" CXXFLAGS="$CXXFLAGS $CFLAGS" LDFLAGS="$LDFLAGS" \
CC="$CC" ./configure --prefix=/usr --bindir=/bin
}
_make () {
make
}
_make_fake_install () {
make DESTDIR=/usr/src/opsystem/${pkg_name}-${pkg_version}-${pkg_release}/bin \
install
}
_build_tbz2 () {
cd /usr/src/opsystem/${pkg_name}-${pkg_version}-${pkg_release}/bin && \
tar cjf /usr/src/opsystem/${pkg_name}-${pkg_version}-${pkg_release}/final/bin.tbz2 *
}
sopp_all () {
_patch_all &&
_configure &&
_make &&
_make_fake_install &&
_build_tbz2
}
c. the package information file (pif), which contains the following information about the future binary package:
Name: bash
Version: 2.05b
Release: 2
Architecture: i686
Depends: readline
Maintainer: Andrei Oprisan
Summary: The Bource Again SHell.
Description: This package contains the Bourne Again SHell (bash). This
Description: shell
Description: is compatible with the standard Unix shells and provides
Description: features above and
Description: beyond those of the traditional ones.
Note that although the description of the package is segmentated on many lines, with some lines having more words than others, the outcoming sumary will be:
This package contains the Bourne Again SHell (bash). This shell is compatible with the standard Unix shells and provides features above and beyond those of the traditional ones.
It must also be noted that the order in which the following lines are presented musn't necesarelly be that which is presented above. For example, we could have the "Name" field as the second to last line and some of the "Description" lines anywhere in the file; as long as they're there, opsystem will extract all the correct information.
d. the pre-install script (optional):
This script may be executed right before the future binary package will be installed in the root folder. It does not have to be executable (with the executable bit set), but as this will be treated as a shell script, it will need to have the string "#!/bin/sh" as the first line.
e. the post-install script (optional):
This script may be executed right after the future binary package will be installed in the root folder. It does not have to be executable (with the executable bit set), but as this will be treated as a shell script, it will need to have the string "#!/bin/sh" as the first line.
f. the pre-remove script (optional):
This script may be executed right before the future binary package will be removed in the root folder. It does not have to be executable (with the executable bit set), but as this will be treated as a shell script, it will need to have the string "#!/bin/sh" as the first line.
g. the post-remove script (optional):
This script may be executed right after the future binary package will be removed in the root folder. It does not have to be executable (with the executable bit set), but as this will be treated as a shell script, it will need to have the string "#!/bin/sh" as the first line.
h. patches (if any):
If in the folder where you invoked mksopp there were any files ending in .patch, they were automatically included in this package and will you will be able to invoke them from the build resource file.
It must be noted that the archive is comprised of at least three (biulddep, buildrc, and the pif file) or more of the above files, and that when compressed, .tar.bz2 compression is used.
The source archive, containing all the source files that will be compiled (.tar.bz2 compressed).