Difference between revisions of "EPrints Package Manager"

From EPrints Documentation
Jump to: navigation, search
Line 1: Line 1:
[[Category:EPM]]
+
[[Category:EPrints Bazaar]]
  
 
=The EPrints Package Manager=
 
=The EPrints Package Manager=

Revision as of 15:26, 16 December 2011


The EPrints Package Manager

This page explains the the core features and aims of the EPrints package manager which will see its debut in EPrints 3.3

Overview

The EPrints Package Manager is basically a cross between a linux package repository and a user friendly GUI store (think fruit flavoured mobile application store). This makes it a highly open platform for developing extensions specific to a single product which has the flexability and functionality of certain closed stores.

The EPM system consists of 2 main parts, EPM repositories and the client side EPM manager which handles packages installed both from an EPM repository as well as those sourced locally. The EPM manager is able to source packages from more than one EPM repository as is defined by the EPM manager configuration file stored relative to each repository. The EPM manager is also responsible for handling the installation, location of upgrades and EPM development of a new EPM compliant package.

In this document we look at each of the feature of the EPM manager, these in turn aid in the development of an EPM package.

What is an EPM package and what it is not!

  • A EPM package consists of a series of files which can be dropped into the ARCHIVE_ID location at any level.
  • An EPM package is not able to patch existing files and will exit if an existing file is not managed by the package being installed.
  • It is possible to perform other changes to the archive not specified in the EPM by adding a custom configuration screen to the package which can be accessed by users after a successful install, more on this later.

EPM Manager Basics

  • Both command line (via bin/ep_bazaar) and GUI access (via the Admin interface)
  • Basic commands/capabilities
    • Install
    • Upgrade (same as install)
    • Remove
    • --force

Example command line

 perl bin/ep_bazaar archive_id install http://domain.com/package.epm --force

The EPM Admin GUI

The EPM admin GUI reflects the command line access and has 4 main tabs which are displayed depending on if there is content to put on them, e.g. the "Installed Packages" tab will not display until you have an EPM installed. The tabs are (in order of display):

Available Upgrades

If a later version of a package is found in an EPM repository to the one you have installed locally, this tab will allow you to install the new version.

Installed Packages

From this tab you can view, remove and configure installed packages.

Available Packages

This tab shows the packages available from the various EPM repositories you have defined.

Local Packages

This tab is the development and advanced administrators tab and allows you to upload a custom package into the EPM manager. Once uploaded these packages are checked for complience to the EPM specification before they can be installed. This also means that this tab is ideal for developmental testing of EPM packages.

The technical side to the EPM Manager (how it works)

Installing & Upgrading

These are essentially the same as the EPM Manager will check each file it is attempting to installed to see if it meets the following conditions.

Before install/upgrade

  • Make a backup of any previously installed version of this package.

During install/upgrade

  • If no file exists at destination install from EPM package, record the installed checksum.
  • If a file exists and is managed by a previous version of this package (by checksum) copy the new one over the top and checksum.
  • If a file exists and is not managed by a previous version of this package (including if it has been changed since the last install), abort and remove files installed to this point, then put back the old files.

After successful install/upgrade

  • Attempt to reload the repository, if this fails, abort and rollback as the user may loose the ability to launch the package manager to do this later!
  • Store checksums, spec file and related package files (e.g. package icon) locally overwriting any previous.

Removing

  • Make a backup
  • Using the checksums file, attempt to remove all files listed if they match their checksum still.
  • If success, remove package cache, else call a forced install with the backup which will cause it to all be put back how it was.

TODO

  • Get postinst/prerm scripts working via a packages configuration screen and define these classes.
  • Add ability to search the EPM repositories to both GUI and command line.
  • Add ability to cache package list as a local dataset which can be searched here rather then centrally.
  • Limit GUI to displaying most popular 20 packages, rest are searched for, this will maintain speed when EPM system gets popular.
  • Add button to local packages tab to allow a custom package to be submitted to the EPrints central EPM repository. In all fairness the button is there but the EPM repository is still under construction.