ODF Toolkit/Efforts/Packaging Modularization
See the Packaging Modularization Efforts mail for a description. The following sections list individual effort items.
(Initial content taken from the Packaging Modularization Efforts mail.)
As detailed in the Sharing packages across products mail, sharing packages across products means that the files that make up a product are no longer installed in a single location (e.g., all files that make up OOo 2.3 at
/opt/openoffice.org2.3 on Unix), but rather spread across multiple locations (e.g., OOo 2.3 spreads across
/opt/openoffice.org2.3, if we decide to remove all the files from OOo that are also available in URE). Although this will mean quite some work to adapt the current code base, it will lead to the most flexible solution.
Two kinds of changes are necessary:
- Adapt the code so that it can work for an installation distributed across multiple trees.
- For specific distributed products, create appropriate installation sets containing appropriate content (e.g.,
rcfiles that cater for the distribution of referenced entities).
(1) is a prerequisite for (2). However, (1) can only reasonably be tested with (2) in place. Hence, work on (1) should be done on a CWS where some preliminary version of (2) is also provided. That is, one or more prototypical distributed products should be added to
instsetoo_native. For example, a distributed OOo that reuses URE (see OOo without URE), or a distributed BrOffice that reuses OOo, or a distributed StarOffice that reuses OOo (although the latter would only be visible to Sun engineering), see Three-Layer OOo. This work will not be lost: Once technology is mature enough, we can use this work on (2) as the base of a actual distributed products. (It is assumed that we can build such distributed products with the current
instsetoo_native technology largely left unchanged. Modifications to the
instsetoo_native technology can be done in later steps if desired.)
So, a more detailed list of necessary changes is:
- Introduce appropriate distributed products to
- Make sure all entry points (start scripts or executables) are in the topmost layer, where users expect them.
- Entities in higher layers need to know the locations of lower layers, and need to address entities in lower layers:
- Start scripts or executables.
rcfiles in higher layers need information from
rcfiles in lower layers. (
versionrc.) Generally, the content of
rcfiles needs to be adapted, and certain
rcfiles need to be split into multiple versions in different layers.
- Libraries in higher layers need to find libraries they depend on in lower layers. On all platforms. (
LD_LIBRARY_PATHis a hack that should be avoided.) Jars too.
- The locations of layers must not be hard-wired, to allow relocation.
- Entities in lower layers need to find (additional or overriding) entities in higher layers:
rcfiles should be searched from top layer to bottom layer. (
- Executables need to find additional “plugin” libraries in higher layers. On all platforms. (
LD_LIBRARY_PATHis a hack that should be avoided.) Where applicable, this can be solved by changing from plain
dlopenplugins to UNO components.
- UNO type and service rdbs (supported by
- Locations of native libraries in
services.rdbare relative (to a single
$ORIGIN), that must be changed. (One possibility might be to make locations within a given service rdb relative to the location of the rdb itself, each layer would bundle its service libraries and a service rdb, and all the rdbs would be on the combined
unorc.) Locations of jars start with
vnd.sun.star.expand:$UNO_JAVA_COMPONENT_PATHand need to be fixed, too.
presetsdirectories from which user installations are copied (
xslt). At least
registryalready supports being spread across multiple directories.
- Executables that only differ in icon etc.: those changes should be factored out if possible. (Windows only.)
share/config/soffice.cfg(menus, toolbars, etc.): (a) located via
org.openoffice.Office/Paths/UIConfig/InternalPaths, (b) needs to support layering itself.
Patches vs. upgrades
(Initial content taken from the Packaging Modularization Efforts mail.)
The OOo code base includes mechanisms to build patch installation sets that only contain those parts that have actually changed relative to some older version of a product, using whatever platform-specific means (for Linux rpm, Solaris packages, and Windows Installer) to get those patch sets as small as possible. This is for example used by StarOffice to produce patch sets from a given major version to one of its minor versions.
However, the nature of those patch mechanisms also means that you cannot do much to the package structure of a product between two minors. You can only jumble the structure for a new major. (For example, some patch formats do not allow to remove an existing file with a patch, so you could not move a file from one package to another, even if the two packages would be in different locations of a distributed product.)
But it might not work to get done all the repackaging things we consider useful in time for a new major OOo 3 (which will inevitably come, sooner or later). We can solve this dilemma by reducing the constraints that the patch feature imposes. For example, we can retain the current patch mechanism for true fix-only (micro) releases, and introduce a coarser upgrade mechanism for minors that always exchanges complete packages. That way, a file could be moved between packages, or a new package could be cut off an existing one, without having to hold off until the next major. Or we can go even one step further and only offer respins (no upgrades) for minors, which would allow for even more freedom in repackaging things in between minors (in the extreme, a minor would not change any files, but only change the packaging structure so that each file ends up in a different package; for such a minor an upgrade would have to include all packages, which would be unfortunate as no file actually changed; with a respin that problem goes away as it includes everything, anyway).
When building various single/multi language installation sets, do not re-build all the packages (especially the locale-independent ones) for each individual installation set.
Ease QA work
Better understand how QA is currently done on the huge set of (slightly) different installation sets, to find ways to systematically reduce the necessary efforts.
Sharing packages across architectures
At least on Solaris SPARC and x86 (which share the same package format), we could already today share packages that do not include native binaries. Experimentations in this area can help better understand how a broader mechanism of sharing (abstract or concrete) packages should work.
It would be nice to not include in OOo installations components that are already available on a system. There are two scenarios to distinguish:
First, components that are bundled with a target platform. If a certain component, in an adequate version, is available on every version of a platform that we target, at a fixed location, we can stop including that component in OOo installations right now. (The installation set should formulate an appropriate dependency on the component, so that it can be installed on demand by the installation process.)
Second, unbundled components, that might or might not already be available in an adequate version on a system. Parts of OOo that need it should address it with a relative path (e.g., Unix
/opt/openoffice.org3/program/vcl.so NEEDS ../freetype/freetype.so). The OOo installation set should include multiple packages that make the component available. One such package provides a link to the component instance available on the system (e.g., the package includes the symbolic link
/opt/openoffice.org3/freetype -> /usr/lib). Another such package provides a local copy of the component (e.g., the package includes the file
/opt/openoffice.org3/freetype/freetype.so). It needs to be decided at deployment time which of those packages to actually install (how that decision is actually made needs to be evaluated, of course).