Top Menu

Jump to content
  • Package manager
    • View all projects
Home
    • Work packages
    • News
    • Getting started
    • Introduction video

      • Welcome to OpenProject

      Get an overview

      Get a quick overview of project management and team collaboration with OpenProject.
      You can restart this video from the help menu
    • Help and support
    • Upgrade to Enterprise Edition
    • User guides
    • Videos
    • Shortcuts
    • Community forum
    • Professional support
    • Additional resources
    • Data privacy and security policy
    • OpenProject website
    • Security alerts / Newsletter
    • OpenProject blog
    • Release notes
    • Report a bug
    • Development roadmap
    • Add and edit translations
    • API documentation
  • Sign in
      Create a new account
      Forgot your password?

Side Menu

  • Overview
  • Activity
  • Work packages
  • News
  • Forums
  • Repository
  • Wiki
    • Table of contents
      • Expanded. Click to collapseCollapsed. Click to showWiki
        • Hierarchy leafCaches and Metadata locations
        • Hierarchy leafConfiguring pkgmanager
        • Hierarchy leafHelp
        • Hierarchy leafInstalling new software
        • Expanded. Click to collapseCollapsed. Click to showPackaging new software
          • Hierarchy leafPackage structure and metadata
          • Hierarchy leaftxz format
        • Hierarchy leafRemoving software
        • Hierarchy leafUpgrading software
You are here:
  • Wiki
  • Packaging new software
  • Package structure and metadata

Content

Package structure and metadata

  • More
    • Table of contents

Package content

A typical package for pkgmanager contains a tree of directory and files meant to be extracted to root and a directory with metadata.

Full example:

/usr/bin/something-awesome
/install/pkgname-2.34.build
/install/pkgname-2.34.dependency
/install/pkgname-2.34.tag
/install/pkgname-2.34.tree
/install/pkgname-postinstall.sh
/install/pkgname-postuninstall.sh
/install/pkgname-preinstall.sh
/install/pkgname-preuninstall.sh
/install/pkgname.conflicts
/install/pkgname.info
/install/pkgname.obsoletes
/install/pkgname.recommends
/install/pkgname.url

Meta file usage and origin

Meta files with version in name are automatically generated. They contain file lists with permissions and hash sums, build number information, tag name and a list of dependencies detected.

Others without version name must be put in place before packaging new software. Not all of them have to be present at once but the url file and info file have to be present to make a proper package. All others are optional and server purposes as described below

Package hooks

Hooks are small bash scripts with a special naming. When placed into the /install directory and packaged with pkgmanager they start being executed if the package in being installed removed or upgraded.

The preinstall file is executed right before the package is extracted to the system. The postinstall file is executed right after the new package was extracted to the system. This functionality is useful if you are updating daemonized services shutting them up and down while upgrading its packages.
Pre and postuninstall files serve the same purpose but only if the package is being uninstalled.

In case if we are updating a package with a full set of shell scripts with another one with a full set too, than the order of executing will be as shown:

  1. preinstall (new package)
  2. postinstall (new package)
  3. preuninstall (old package)
  4. postuninstall (old package)

Conflicts, recommends, obsoletes

The conflicts, recommends and obsoletes files contain package names.

If we have package A in B.conflicts then installation of A alongside B wont be allowed

If we have package A in B.obsoletes then A will be uninstalled and B installed.

If we add package A to B.recommends then A and be will be installed.

Loading...