ODF Toolkit/Efforts/Packaging Modularization

From Apache OpenOffice Wiki
Jump to: navigation, search

See the Packaging Modularization Efforts mail for a description. The following sections list individual effort items.

Distributed products

(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.org/ure and /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:

  1. Adapt the code so that it can work for an installation distributed across multiple trees.
  2. For specific distributed products, create appropriate installation sets containing appropriate content (e.g., ini/rc files 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 scp2 and 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 scp2/instsetoo_native technology largely left unchanged. Modifications to the scp2/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 scp2/instsetoo_native.
  • 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.
    • ini/rc files in higher layers need information from ini/rc files in lower layers. (bootstraprc, configmgrrc, jvmfwk3rc, setuprc, sofficerc, unorc, versionrc.) Generally, the content of ini/rc files needs to be adapted, and certain ini/rc files 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_PATH is 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:
    • ini/rc files should be searched from top layer to bottom layer. (bootstraprc, configmgrrc, jvmfwk3rc, setuprc, sofficerc, unorc, versionrc.)
    • Executables need to find additional “plugin” libraries in higher layers. On all platforms. (LD_LIBRARY_PATH is a hack that should be avoided.) Where applicable, this can be solved by changing from plain dlopen plugins to UNO components.
    • UNO type and service rdbs (supported by unorc UNO_TYPES and UNO_SERVICES).
    • Locations of native libraries in services.rdb are 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 UNO_SERVICES path from unorc.) Locations of jars start with vnd.sun.star.expand:$UNO_JAVA_COMPONENT_PATH and need to be fixed, too.
    • presets directories from which user installations are copied (desktop/source/app/userinstall.cxx:1.21 create_user_install).
    • Distributed .res files (program/resource directories; tools/source/rc/resmgr.cxx:1.43 ResMgrContainer::init).
    • Distributed share subdirectories (autocorr, autotext, basic, config, dict, dtd, fonts, gallery, psprint, registry, Scripts, template, wordbook, xdg, xslt). At least registry already supports being spread across multiple directories.
    • Optional about.bmp and intro.bmp in the program directory.
  • 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 configmgr org.openoffice.Office/Paths/UIConfig/InternalPaths, (b) needs to support layering itself.
  • Correct -env:UNO_SERVICES= in raise_uno_process in desktop/source/deployment/registry/component/dp_component.cxx:1.15.

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.

External components

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).

Personal tools