A package would be compiled normally, and the files needed for the installation would be inside a folder named "root".
There will be two special files above the "root" folder: "pet2.specs" and "pinstall". See below for their specifications.
*TODO: should there be a root/ folder, or the package files be in / with pet2.specs?*
A possible package folder before compression may look like:
/tmp/build/
/tmp/build/pet2.specs
/tmp/build/pinstall
/tmp/build/bash/
/tmp/build/bash/bin/
/tmp/build/bash/bin/bash
/tmp/build/bash/bin/sh
A PET2 file will be a squashfs filesystem with a .pet2 suffix. It's full name will be formatted as:
packagename[_DOC/_DEV/_NLS]-version-revision.arch.pet2
Where [_DOC/DEV/NLS] is optional (the EXE will have nothing, the DOC will have "_DOC", the DEV will have "_DEV", and the NLS will have "_NLS").
The squashfs will be compressed by running the command (with extra options, if reqired):
mksquashfs root/ pet2.specs pinstall full_package_name.pet2 -comp xz
Using the bash example above, you can use the following commands to create a PET2 package:
mv bash/ root/
mksquashfs root/ pet2.specs pinstall bash-4.2-1.i686.pet2 -comp xz
mv root/ bash/
To test if your pet2 was created correctly, you can run:
unsquashfs packagename-version-revision.arch.pet2 pet2.specs
ls squashfs-root/
If you don't see "pet2.specs" outputted, or if there are errors, then your package was not created correctly.
The pet2.specs file will be a bash script which includes all of a package's info. It would look something like:
# comments can be included by starting a line with a "#"
pkgname:bash
pkgver:4.2
pkgrev:1
pkgarch:i686
pkgdesc:A shell interpreter
# supported version compairasons are: =, <, >, <=, and >=
pkgdeps:glibc>2.0
pkgdeps:bash-support
provides:sh
The fields will look like: varname:value
If a value has multiple values (dependencies), the variable name would appear multiple times, as shown with the "pkgdeps" variable
*TODO: what other fields should there be?*
The pinstall file will be an optional file inside the root directory of a package. It will be a bash script with any needed bash functions defined (unneeded functions do not need to be defined). The functions with arguments will be (for EXE):
pre_install(newversion-revision)
post_install(newversion-revision)
pre_upgrade(newversion-revision oldversion-revision)
post_upgrade(newversion-revision oldversion-revision)
pre_uninstall(oldversion-revision)
post_uninstall(oldversion-revision)
There can also be a function for DEV, DOC and NLS packages, by appending an underscore and the package name to the function name, so "pre_install()" will become "pre_install_DEV()" if the DEV needs a script to run before being installed.
Please note that multiple scripts may be run during the same installation ("pre_install()" and "pre_install_DEV()" can be run at the same time if the DEV package is included in the EXE package). The functions will always be run in this order (if the split package part is being installed and the function exists), where * is install, upgrade or uninstall:
pre_*, pre_*_DEV, pre_*_DOC, then pre_*_NLS
(install, upgrade or uninstall package files)
post_*, post_*_DEV, post_*_DOC, then post_*_NLS
Each package and package list in the official repositories will be signed. This lets users know that somebody has not modified the package. Packages outside the official repositories do not have to be signed.
Packages will be signed using GPG, using a detached signature (a .pet2.sig file). An example command that would sign a package is:
gpg --detach-sign -u ABCDEFAB packagename-version-revision.arch.pet2
Where "ABCDEFAB" is the key ID you wish to sign the package with.
See the first post in this thread.
There are three main parts to the format: the pet2.specs, pinstall, and the compression format.
pet2.specs:The current pet.specs file holds a package's information, but it isn't readable or writable by humans, and it is hard to add more fields to.pinstall:
The pet2.specs is easily readable, easily writable (with a template for field names), and is easy to add more fields to. It is also pretty easy for computers to extract values from.
The current pinstall and puninstall work, but they do not provide support for split packages being merged, or for pre-install scripts. The new pinstall file would include everything in one file, which allows code to be reused.Compression format:
While using .tar.xz package files would be somewhat smaller their SFS counterparts, they do not have some of the advantages SFS packages have. With SFS packages, it would allow users to choose if they want to install the package the normal way by copying the files to the save file/partition, or be mounted (like the current SFS packages) to save space.