Difference between revisions of "User:Kr/Packaging"

Revision as of 14:44, 11 January 2008

OpenOffice.org (OOo) and its derivatives are complex products. Many features, templates, configuration files, registry entries, binaries, localizations etc. need to be delivered and deployed in a reliable and platform compliant way, while giving the user broad choice regarding the particular features he wants to actually install.

OOos growing ecosystem brings the current approach to its limits, we are currently facing a set of problems, which the below proposed solution is going to address. OOo based products need to support different platforms (Operating System / Machine Architecture) as well as different deployment systems (e.g. RPM, Debian, Ports, Solaris Packages, MS Windows Installer Service), localizations and feature sets, as well as they need to be easy to extend and maintain.

Overview

Some clarification is needed regarding the terms to describe how to deploy, update, maintain and configure a particular software program.

Software Programs

A (software) program is an executable for a particular platform (operating system and/or machine architecture (e.g. x86, x64)). Software programs are delivered as products to customers.

Products

A product consists of a particular set of features and localizations targeted to a particular set of platform(s) and deployment systems, while being provided as a set of bits e.g. on CD or floppy disk or as a download.

A product typically has a brand as well as predecessor products and may require other products to be installed.

Deployment

As OOo is cross platform (operating system / machine architecture), OOo installation sets need to integrate with different deployment systems.

Deployment systems to be supported are at least

• MS Windows Installer Service,
• Red Hat Package Manager,
• Debian Packages / Advanced Packaging Tool (APT),
• Solaris Packages and
• Mac OS X Packages.

These deployment systems can be categorized as to be

• package oriented and / or
• product oriented.

Updates

Over time, programs become updated with bug fixes, features, usability improvements etc. During the deployment of updates older versions may be de-installed or altered respectively completed. Updates may be provided as dedicated products or as implicit downloads.

Deployment Systems

Package Based Deployment

Package based deployment systems typically lack product orientation, e.g. in a package oriented deployment system, the user typically only sees the deployed packages in the systems configuration, he is neither able to directly see which products are represented by which packages, nor which additional features are available. To remove a particular product the user needs to find and to remove all belonging packages (sometimes even the indirectly installed packages) typically by searching the package database.

Package based deployment systems enable sharing of packages between products, allowing for re-usage of particular files or functionalities.

Packages can typically be set into relationship to one another. The following are typical relationships,

• one package may depend on one or many another packages,
• one package may conflict with one or many other packages,
• one package may replace one or many other packages,
• one package may suggest one or many other packages.

Program updates may be deployed at least on a package granularity, while some deployment systems even support patch packages (packages which only contain the differences between a particular package and its successor).

Product Based Deployment

In a product oriented deployment system, the user sees the installed products in the systems configuration. Customization is typically supported by product, offering not yet installed features as well as allowing to remove the product as a whole.

Product based deployment systems may allow sharing of entities (e.g. files) on some level.

Product based deployment systems typically allow to set products into predecessor / successor relationship.

Product based deployment systems mostly only support product updates on a product level, e.g. as new products or as product patches, which may only be applied to one particular product.

OOo relevant Deployment Systems

.pkg

.deb/apt

Relations:

• "depends"
• "recommends"
• "conflicts"
• "suggests"
• "replaces"
• "pre-depends"
• "breaks"

Tags:

• "priority"
• "section"

Features:

• "manual install"

.rpm

Relations:

• "provides"
• "requires"

MS Windows Installation Service

Though not providing package granularity at installation time, MS installer provides similar functionality at product creation time (.msm).

Features:

• installation on demand
• advertisement ("assigning" / "publishing")
• customization
• patching / updating
• usage metrics on features - automagic de-installation
• Incorporated installations == ? "dependencies" ?
• Resiliency
• User / Machine wide installation
• Installer functions (API for MSI)
• Administrative Installation

Links:

• http://msdn2.microsoft.com/en-us/library/aa372866.aspx

Mac OS X

Requirements

Version

Software provided to a customer typically has a version, describing timely variant. Typically older variants have smaller version the younger variants. Versions may be differentiated into Major, Minor and Micro.

Relationship

• No relationship -> self contained
• Update relationship
  • update only (e.g. add-ons, localizations)
  • self contained (e.g. OOo 2.1 updating OOo 2)
  • Multi-update relationship
    • Cross version (major / minor / micro)
    • Cross language
    • Cross brand
    • Cross variant
    • Cross platform

Development

Support for Changes:

• updated package(s)
• (automatically) remove package(s)
• add package(s)
• rename package(s)

• remove file(s)
• add file(s)
• move file(s)

Program Management

In a perfect world, program management would be able to create any kind of product, only depending on business needs, not at all restricted by technical constraints.

Program Management basically mediates between marketing / market requirements and the pool available technologies.

Constraints

Compatibility

As a product evolves, its interfaces may change in an incompatible fashion. For binary packages mostly interesting are

• ABI (Application Binary Interface) incompatible changes, as well as
• structural incompatible changes (removed / renamed files).

Some installation units try to stay compatible, expressing the change of compatibility in their version numbers, while others may change incompatible with every version.

Version numbers expressing compatibility are typically used as follows,

• a change in a micro keeps a unit compatible, providing bug fixes,
• a change in a minor keeps a unit compatible, providing additional features,
• a change in the major shows an incompatible change.

Approach

Model "products" by setting them into

• inheritance, respectively
• structural

relationship.

Inheritance

Inheritance models a "is a" relationship. In practice that would mean, that a StarOffice 8 update 7 is an OOo 2.2.1 (respectively its basis) adding something.

Example Modelling

Template Product OOo-Standard {
  Features: writer, calc, impress, draw
}


Abstract Product OOo2.4 {
  Name: OOo 2.4
  Code-Base: SRC680m236
  Implements: OOo-Standard

}

Product OOo2.4-ISO : OOo2.4 {
  Name: OpenOffice 2.4
  Format: ISO-750
  Platform: Linux-x86, Windows-x86, Mac OS X x86
}

Product OOo2.4-download-linux-x86 : OOo2.4 {
  Name: OpenOffice 2.4
  Format: donwload
  Platform: Linux-x86
}

Product OOo2.4-download-windows-x86 : OOo2.4 {
  Name: OpenOffice 2.4
  Format: donwload
  Platform: windows-x86
}

Abstract Product SO8u9 : OOo2.4 {
  Name: StarOffice 8 update 9
  Features: so-templates, so-fonts, so-spellchecker, so-brand
  Updates: < StarOffice 8 u 9
}

Product SO8u9-ISO : SO8u9 {
  Name: StarOffice 8 update 9 ISO
  Format: ISO-750
  Platform: Linux-x86, Solaris-x86, Solaris-Sparc, Windows-x86, Mac OS X x86
}

Product SO8u9-donwload {
  Name: StarOffice 8 update 9 ISO
  Inherits: SO8u9
  Format: download
  Platform: Linux-x86
}


Abstract Product {
  Name: StarSuite 8 update 9
  Inherits: OOo 2.4
  Features: so-templates, so-fonts, so-spellchecker, ss-brand
  Updates: < StarSuite 8 u 9
}

Tooling

• Comparison of Installation Sets
• Check for conflicts
• Creation of Installation Sets
• Visualization

Example Implementation

Example Product creation for by target platform.

Linux

Mac OS X

Solaris

Windows

Experiments under Windows with WiX (Windows Installer XML) show,

• that any set of products may share any number of files,
• that any one product may update any number of other products (basically leading to a de-installation of these other products), and
• that any product sharing files with other products may update any number of these shared files.

This lets me think, that Windows is as dynamic and flexible as the classic package based platforms, while providing a simpler user interface.

Merge Modules

"In order to avoid versioning problems, you should use always merge modules for any component or file that will be shared by multiple applications." [1]

Simple Installation Set