Difference between revisions of "User:Kr/Packaging"

From Apache OpenOffice Wiki
Jump to: navigation, search
m
m (Installation System)
Line 28: Line 28:
  
 
==Installation System==
 
==Installation System==
There a basically two types of installation systems around,
+
There are basically two types of installation systems around,
 
* one using the "package" as the basic building block (e.g. .rpm or .deb), creating products by combining packages,
 
* one using the "package" as the basic building block (e.g. .rpm or .deb), creating products by combining packages,
 
* the other supporting the "product" as the installation unit (e.g. Windows, Mac?).
 
* the other supporting the "product" as the installation unit (e.g. Windows, Mac?).
  
In "package" based installations, the user typically sees the "packages" in the systems configuration, being able to tweak a product by (de-)selecting packages, while product based installations leave it to the actual product, to provide customization options.
+
In "package" based installations, the user typically sees the "packages" in the systems configuration, being able to tweak a product by (de-)selecting packages, while "product" based installations leave it to the actual product, to provide customization options.
  
 
===Package Based Installation===
 
===Package Based Installation===
Line 61: Line 61:
 
* "provides"
 
* "provides"
 
* "requires"
 
* "requires"
 
  
 
===Product Based Installation===
 
===Product Based Installation===
Line 83: Line 82:
  
 
====Mac OS X====
 
====Mac OS X====
 +
 
==Requirements==
 
==Requirements==
 
===Development===
 
===Development===

Revision as of 09:59, 12 November 2007

Product

A Product is a set of bits, e.g. an ISO image or a self extracting exe.

A product may be described by

  • the source code to be used (e.g. a CVS repository and a CVS tag), this is the products code base,
  • it's features, as well as the brand and the localization to be included, and the configuration used while building, this is the products variant,
  • it's relationship to previous products, this may be something as "patch", "update", "respin" or "add-on", this is the products type,
  • the format of its bits, e.g. "ISO image", "self extracting archive" or "APT repository", this is the products format.
  • the target platform (architecture and Operating System), e.g. Solaris Sparc, Linux x86 or Windows x64, this is the products platform.

E.g.

SO8u9Solx86-CD = SRC680_m236, [{StarOffice}, {Writer, Calc, Impress, Draw}, {English, German}], Update-to(SO8u1), ISO, Solaris/x86

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

Installation System

There are basically two types of installation systems around,

  • one using the "package" as the basic building block (e.g. .rpm or .deb), creating products by combining packages,
  • the other supporting the "product" as the installation unit (e.g. Windows, Mac?).

In "package" based installations, the user typically sees the "packages" in the systems configuration, being able to tweak a product by (de-)selecting packages, while "product" based installations leave it to the actual product, to provide customization options.

Package Based Installation

Package based installation allows for sharing of packages between products. Having the consequences,

  • that one product may update another product, to function better,
  • that two products may conflict.

.pkg

.deb/apt

Relations:

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

Tags:

  • "priority"
  • "section"

Features:

  • "manual install"

.rpm

Relations:

  • "provides"
  • "requires"

Product Based Installation

.msi

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:

Mac OS X

Requirements

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

Proposed Approach

Example Implementation

Example Product creation for by target platform.

Linux

Mac OS X

Solaris

Windows

Simple Installation Set

Product Description=

Personal tools