Difference between revisions of "User:Kr/Packaging"
m (→Windows) |
m |
||
Line 1: | Line 1: | ||
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. | 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. To actually understand the problems, we first need to take a look at the products we and others currently deliver, and at the products we would like to offer. | |
− | == | + | ==Deployment Systems== |
− | + | 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 either be | |
− | + | * package oriented or | |
+ | * product oriented. | ||
− | === | + | ===Package Based Deployment=== |
− | + | In package oriented deployment systems, the user typically only sees the packages of a particular product in the systems configuration, being able to tweak a product by (de-)selecting packages only. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Package based installation allows for sharing of packages between products. Having the consequences, | Package based installation allows for sharing of packages between products. Having the consequences, | ||
* that one product may update another product, to function better, | * that one product may update another product, to function better, | ||
Line 46: | Line 27: | ||
====Package Relationship==== | ====Package Relationship==== | ||
− | In | + | In package based deployment systems, packages may relate to each other. Example relationships are |
* depends, | * depends, | ||
* conflicts, | * conflicts, | ||
− | * replaces | + | * replaces or |
* suggests. | * suggests. | ||
These relationships are often modelled more fine grained by using version numbers. | These relationships are often modelled more fine grained by using version numbers. | ||
Line 77: | Line 58: | ||
===Product Based Installation=== | ===Product Based Installation=== | ||
− | ==== | + | In a product oriented deployment system, the user sees the installed products in the systems configuration. Customizations are done with product specific dialougs etc. |
+ | |||
+ | ====MS Windows Installation Service==== | ||
Though not providing package granularity at installation time, MS installer provides similar functionality at product creation time (.msm). | Though not providing package granularity at installation time, MS installer provides similar functionality at product creation time (.msm). | ||
Line 96: | Line 79: | ||
====Mac OS X==== | ====Mac OS X==== | ||
+ | |||
+ | |||
+ | ==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 | ||
+ | |||
==Requirements== | ==Requirements== |
Revision as of 12:31, 10 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. To actually understand the problems, we first need to take a look at the products we and others currently deliver, and at the products we would like to offer.
Contents
Deployment Systems
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 either be
- package oriented or
- product oriented.
Package Based Deployment
In package oriented deployment systems, the user typically only sees the packages of a particular product in the systems configuration, being able to tweak a product by (de-)selecting packages only.
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.
Package based installation is an opportunity!
Package Relationship
In package based deployment systems, packages may relate to each other. Example relationships are
- depends,
- conflicts,
- replaces or
- suggests.
These relationships are often modelled more fine grained by using version numbers.
.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
In a product oriented deployment system, the user sees the installed products in the systems configuration. Customizations are done with product specific dialougs etc.
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:
Mac OS X
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
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
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]