CID/Packaging-Concept

Packaging Concept for p≡p Engine and Adapters

Guidelines

Packages for each distro should take care to follow distro/OS guidelines. Some general rules are as follows:

  • For most Linux distros we sill set the install path to /usr, so that libs go into /usr/lib, binaries into /usr/bin, and so on.
  • NOTE: An explicit exception to this rule is for special projects which are not for wide public use and may have non-standard usage requirements; Wherein we may choose to set the install path to /opt/<project name> for the benefit of software isolation and usage of multiple versions on a single machine.

  • Packages should use system dependencies wherever possible.

  • Packges should make an effort to make upgrades automatic and safe. Eg. if database changes are required for an upgrade, then the package should verify the current database, make a backup, attempt a migration, and revert to the old database upon failure.

  • For non-release builds, packages names should contain the date and the VCS commit hash at time of build.

RHEL

Specifics for Redhat Enterprise Linux (RHEL)

Paths

  • Libraries
    • p≡p Engine & Adapters
      • /usr/lib
  • Libraries
    • Deps (eg. etpan, sequoia)
      • /usr/lib/pEp
  • Binaries
    • Adapters, p≡p utilities
    • /usr/bin
  • Share Directory
    • /usr/share/pEp
  • system.db
    • /usr/share/pEp/system.db
  • Headers
    • p≡p Engine & Adapters
      • /usr/include/pEp
  • User Directory
    • $HOME/.pEp
  • Manpages
    • /usr/share/man/man*