Efforts/Package Restructuring/Proposal

What we need for OOo is partly already available, partly not. Ideally we would be able to represent OOo as well as derivatives by a Product View on all our target platforms. This Product View would than allow to update, extend and to (partly) de-install it. Getting any needed data from one or multiple media / repositories. This Product View would need to be accessible from inside the product as well as from the platforms standard location (e.g. "Add or Remove Program" on MS Windows), if any.

The "extension manager" (tools/Extension Manager) already offers some update / installation capabilities from inside OOo, restricted to extensions.

Some platforms also provide mechanisms for system update and maintenance, certainly an installed OOo, respectively derivative, needs to integrate with this as well.

Combining these things gets kind of complicated, remembering that parts of OOo may be installed system wide (e.g. "core" components), while others may be installed per user only (e.g. extensions).

Usage Scenarios

Extensions

Extensions are treated as standard Office features and may therefore be added, customized, removed or updated via the Product View.

Requirements

So, what actually is needed is

• product independent update, as supported by packages,
• Product View, to customize or complete a particular installation,
• dependency support,
• certainly versioning,
• patch support,
• system/user repository support, to enable product maintenance by standard maintenance actions (e.g. apt-get update; apt-get upgrade),
• system installation, to make the product available for multiple users,
• user installation, to make the product available for single users.

Non of OOos target deployment systems support all of these features / requirements. Some deployment systems provide APIs, hopefully enabling the implementation of missing desired features. Systems not providing a way to realize a particular feature may be left without it.

Product Independent Update

Product independent updates allow to share updates between different products. For example the Uno Runtime Environment (URE) is shared by OOo and its derivatives such as StarOffice and StarSuite. If products can only be updated product by product, than all derivatives have to offer updates for their particular products, even if the update only provides changes e.g. to the underlying Uno Runtime Environment, thus all updates being identical.

The package oriented systems typically treat any package as a product, while still allowing these packages (products) to require each other. Hence, package oriented systems allow product independent updates anyway.

Product View

The product view allows to see the parts of an installed product in their product context. Ideally allowing to customize these parts as well as to install other product parts, either from a medium such as a CD, or from any other repository.

Package oriented systems typically lack a product view, especially making it hard to de-install a particular product as well as to install completing parts.

Dependencies

Dependencies enable composition of products by other products. Required (sub-) products may even be installed and de-installed automatically (cascaded de-installation), satisfying other products dependencies.

Package oriented systems typically support dependencies, while product oriented mostly do not do so.

Versioning

Most concrete products are released over time as different versions of an abstract product. Mostly newer versions replacing older ones.

Versioning is supported by most deployment systems.

Patches

Deployment systems use some level granularity for deploying a products entities. This units are sometimes called packages or components. Patches allow to provide updates on a sub granularity level, e.g. enabling smaller downloads.

Repositories

Some systems use repositories to ease system maintenance and customization. These repositories typically list latest versions of software products, while enabling the user / administrator to easily update or customize the system.

Deployed products certainly need to be maintained in the same way as the underlying system, ideally being listed and available in these repositories.

In case user product installation is supported, a system may provide user installation repositories as well as system repositories.

User/System Installation

Software may be provided as system software, installed by an administrator, or as user dedicated software, installed by user.