Difference between revisions of "User:Kr/Packaging"

From Apache OpenOffice Wiki
Jump to: navigation, search
m (→‎Installation System)
m (→‎Implementations: Moved to Efforts/Package_Restructuring/Backends)
 
(82 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
==Product==
+
Todos:
−
A Product is a set of bits, e.g. an ISO image or a self extracting exe.
+
* Split this into multiple pages.
 +
* Add testing, testability and QA.
 +
* List the stakeholders.
 +
* Add "few deliverables as possible" goal.
 +
* Add 3rd party staff to be separated.
  
−
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===
+
==Overview==
−
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'''.
+
Some clarification is needed regarding the terms to describe how to deploy, update, maintain and configure a particular software program.
  
−
===Relationship===
+
===Products===
−
* No relationship -> self contained
+
A product consists of a particular set of features and localizations targeted to a particular set of platforms and deployment systems. A product is a set of bits provided by a medium such as a CD, a floppy disk or as a download. A product typically has a brand as well as predecessor and successor products and may require other products to be installed. Independent Products assembled of other (sub-) products may share these (sub-) products, even if these (sub-) products are implementation details only.
−
* 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==
+
===Deployment===
−
There are basically two types of installation systems around,
+
As OOo is cross platform (Operating System / Machine Architecture), OOo installation sets need to integrate with different deployment systems.
−
* 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.
+
These deployment systems can be categorized as to be
 +
* package oriented (such as RPM) and / or
 +
* product oriented (such as MS Windows Installer).
  
−
===Package Based Installation===
+
====Package Support====
−
Package based installation allows for sharing of packages between products. Having the consequences,
+
Package oriented deployment systems typically lack product support, e.g. in a package oriented deployment system, the user typically only sees the deployed packages in the systems configuration and 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.
−
* that one product may update another product, to function better,
+
−
* that two products may conflict.
+
  
−
====.pkg====
+
Package oriented deployment systems enable sharing of packages between products, allowing for re-usage of particular files or functionalities.
−
====.deb/apt====
+
−
Relations:
+
−
* "depends"
+
−
* "recommends"
+
−
* "conflicts"
+
−
* "suggests"
+
−
* "replaces"
+
−
* "pre-depends"
+
−
* "breaks"
+
  
−
Tags:
+
Packages can typically be set into relationship to one another. The following are typical relationships,
−
* "priority"
+
* one package may '''require''' on one or many another packages,
−
* "section"
+
* 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.
  
−
Features:
+
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).
−
* "manual install"
+
  
−
====.rpm====
+
====Product Support====
−
Relations:
+
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.
−
* "provides"
+
−
* "requires"
+
  
−
===Product Based Installation===
+
Product based deployment systems may allow sharing of entities (e.g. files) on some level (e.g. "component", see below).
−
====.msi====
+
−
Though not providing package granularity at installation time, MS installer provides similar functionality at product creation time (.msm).
+
  
−
Features:
+
Product based deployment systems typically allow to set products into predecessor / successor relationship.
−
* 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:
+
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.
−
* http://msdn2.microsoft.com/en-us/library/aa372866.aspx
+
 
 +
===Updates===
 +
Over time, new versions of products are released, providing bug fixes, additional features, usability improvements etc. During the deployment of product updates the older versions may be de-installed or altered respectively completed. Updates may be provided as dedicated products or as implicit downloads.
  
−
====Mac OS X====
 
  
 
==Requirements==
 
==Requirements==
−
===Development===
+
 
 +
===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 any 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 the micro version signals for bug fixes only,
 +
* a change in a minor version signals additional features,
 +
* a change in the major signals an incompatible (API / ABI etc.) change.
 +
 
 +
The OOo productizer needs to support compatibility changes, such that different versions and derivatives may be installed without conflict side by side.
 +
 
 +
===Deployment Systems===
 +
Deployment systems to be supported by OOo are at least
 +
* [http://msdn2.microsoft.com/en-us/library/aa372866.aspx MS Windows Installer],
 +
* [http://www.rpm.org Red Hat Package Manager],
 +
* [http://en.wikipedia.org/wiki/Dpkg Debian Packages]
 +
* Solaris Packages and
 +
* Mac OS X Packages.
 +
 
 +
===Developers===
 
Support for Changes:
 
Support for Changes:
 
* updated package(s)
 
* updated package(s)
Line 96: Line 83:
  
 
===Program Management===
 
===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.  
+
In a perfect world, program management would be able to create any kind of product, only depending on business needs, not restricted by technical constraints.  
  
−
Program Management basically mediates between marketing / market requirements and the pool available technologies.
+
Program Management basically mediates between marketing / market requirements and the pool of available technologies.
 +
 
 +
Program management requires the following product relationships to be supported:
 +
* 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
  
−
==Constraints==
 
  
−
==Proposed Approach==
 
  
−
==Example Implementation==
 
−
Example Product creation for by target platform.
 
  
−
===Linux===
 
  
−
===Mac OS X===
+
==Links==
 +
* Autopackage[http://autopackage.org/]
 +
* RPM[http://www.rpm.org]
  
−
===Solaris===
 
  
−
===Windows===
+
[[Category:Packaging]]
−
====Simple Installation Set====
+
−
Product Description=
+

Latest revision as of 09:36, 25 January 2008

Todos:

  • Split this into multiple pages.
  • Add testing, testability and QA.
  • List the stakeholders.
  • Add "few deliverables as possible" goal.
  • Add 3rd party staff to be separated.


Overview

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

Products

A product consists of a particular set of features and localizations targeted to a particular set of platforms and deployment systems. A product is a set of bits provided by a medium such as a CD, a floppy disk or as a download. A product typically has a brand as well as predecessor and successor products and may require other products to be installed. Independent Products assembled of other (sub-) products may share these (sub-) products, even if these (sub-) products are implementation details only.

Deployment

As OOo is cross platform (Operating System / Machine Architecture), OOo installation sets need to integrate with different deployment systems.

These deployment systems can be categorized as to be

  • package oriented (such as RPM) and / or
  • product oriented (such as MS Windows Installer).

Package Support

Package oriented deployment systems typically lack product support, e.g. in a package oriented deployment system, the user typically only sees the deployed packages in the systems configuration and 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 oriented 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 require 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 Support

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 (e.g. "component", see below).

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.

Updates

Over time, new versions of products are released, providing bug fixes, additional features, usability improvements etc. During the deployment of product updates the older versions may be de-installed or altered respectively completed. Updates may be provided as dedicated products or as implicit downloads.


Requirements

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 any 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 the micro version signals for bug fixes only,
  • a change in a minor version signals additional features,
  • a change in the major signals an incompatible (API / ABI etc.) change.

The OOo productizer needs to support compatibility changes, such that different versions and derivatives may be installed without conflict side by side.

Deployment Systems

Deployment systems to be supported by OOo are at least

Developers

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 restricted by technical constraints.

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

Program management requires the following product relationships to be supported:

  • 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



Links

Retrieved from "https://wiki.openoffice.org/w/index.php?title=User:Kr/Packaging&oldid=61670"
Personal tools