Author: Marco Fioretti
In OpenOffice.org (OOo), extra features and extensions can be distributed inside OOo files or packaged in their own, cross-platform format. Many members of the OOo community would like to see a full-blown extension installer fully integrated into the program. Most GNU/Linux distributors, however, see this and other non-native, application-specific installers (from the CPAN shell to the one for Firefox extensions) just as a “cause of much annoyance and grief.”
GNU/Linux distributions are each based on a single software management database with one update model and one standard user interface. With this vision, any other tool-specific installer is a problem, as it tries to do the same job without a complete view of the system. This applies also to all OOo extensions, including things like macros, templates and clip art. If they were available in the same package format as the rest of the software, their installation and upgrades could be handled automatically. Also, using only native packages, only the very few people who create them (not necessarily the developers) need to know and worry about what is installed and where — not the end users. With a proper quality check, each system file belongs to only one package, and conflicts between system and user-level configuration are much less probable. When one file does have a problem, you know what package owns it and fixing it is sufficient to heal the system. Many GNU/Linux system administrators feel the same way: they want to install and update packages for all their users without human intervention. Most of them also don’t want users to install anything without using the system package manager (rpm, apt, or whatever) being consulted or upgraded. Neither category finds anything so special about OpenOffice.org to justify an exception.
OpenOffice or KOffice? OpenDocument, silly!
Even as a simple end user — not a GNU/Linux distributor — I have another reason to wish that at least some categories of OOo extensions become widely available as native GNU/Linux packages. After all the explanations of how great OpenDocument is, it’s time to start determining and documenting how to distribute OpenDocument templates — not OOo or KOffice ones. The same applies to clip art and, some day, macros. Once the file format becomes the same, is there any real reason to scatter its templates across portals otherwise devoted only to OOo or KOffice? Or to manually configure each program to put them in many different directories? On a GNU/Linux box all this stuff should be installed once and be immediately usable by any application, including automatic text processing systems, Web services and whatnot. Only native packaging can guarantee this.
How OOo extensions work
OOo extensions are packaged as Universal Network Objects (UNO). UNO packages are self-contained zip files. No external dependencies are allowed: files are only placed inside the OOo folders, each component gets its own subfolder and nothing is overwritten anywhere else. There are GUI and command line installers distributed with OOo that also perform all the necessary configuration steps. These tools can be run with user or root permissions and can deploy on a per user or per system basis. The command line version can also be used in a fully automated way.
For all these reasons, OOo developers don’t see any problem with UNO packages. They also point out that sometimes allowing normal users to install personal add-ons may be desirable. Apart from this, their tools can remove everything from any installation cleanly. Add-ons created today will still run with future versions of OOo because the API is under complete control and kept compatible. The Tools -> Package Manager menu item can be disabled with a simple configuration file. Completely preventing user-installable add-on packages is awkward, but can also be done without changing code. The only feature missing today is digital signing of packages, but its addition is already planned. Above all, if extensions have no external dependencies, there shouldn’t be any need to inform the native package manager when they are installed (of course, this assumes that everybody agrees on the definition of “OpenOffice-only extension”). Finally, in practice it will never happen that all extensions of such a program will always be released by their authors in every package format out there. but this is not a big deal because one can easily create a native package (let’s say an RPM) containing the zip file with a post-install script which launches the command line UNO installer.
How to make everybody happy
UNO packaging surely has far fewer problems than other systems. However, it is not suitable for all possible OOo contributions, and native, integrated package management still holds too many advantages to not request it as often as possible. There are two scenarios here: all OOo source code contributors and the more or less casual authors of what I’ll call “OOo material”: macros, templates, dictionaries, and clip art. The first group seems really worried (much more than necessary, in my humble opinion) about being required to prepare and forever maintain all the possible combinations of “native Linux packages” for OOo and every one of its add-ons. Can you blame them, especially when the great majority of their users still run Windows? When it comes to “OOo material” there is a different problem: UNO packaging is not really suited for that sort of thing. Most of it, however, either isn’t packaged at all (just uploaded to a Web site) or, in the case of macros, packaged in the wrong way — distributed only inside manually executable OOo files. These are the cases where all the problems mentioned at the beginning do happen. Luckily, their solution is the same of the first case, and it is easily applicable also by those OOo contributors who are not programmers, or will never run GNU/Linux. Basically, all that is needed is to make sure that everything is always made available online in a properly labeled source format that GNU/Linux distributors can pick and package in their own way without manual intervention and, whenever possible, without having OOo installed on their packaging server. This is simpler than it looks. The first thing needed is a possibly distro-specific way to specify an installation prefix for the UNO installer. Then, in a nutshell, one would only have to adopt strict numbering and naming rules for each version of their package, release it as a compressed archive in tar.bz2 format when applicable, and allow installation in a fully automated way. Then they would announce that the archive is ready for packaging on various GNU/Linux developer lists and put a friendly note up to users, telling them that they might be better off installing the native Linux package of the material rather than downloading the source.
Do you really need OpenOffice.org?
Right now, to install (and package) an UNO bundle, whatever its content is, you need a complete OpenOffice.org installation. This is a problem, since it may introduce unnecessary dependencies both on the target and/or the package building system. The details still need to be worked out, but OOo developers are available to support the integration and coexistence of their installer with any other installer for GNU/Linux or other platforms. If you’re interested, the right forum to join is dev@udk.openoffice.org.
Conclusion
I’m confident that OOo core developers and GNU/Linux distributors will work out a common strategy to deal with UNO packages, and I hope that something similar will happen with Firefox, Perl modules and other systems that have the same problem. As far as office templates, clip art, and similar extras are concerned, the solution is different, and surely easier: this kind of digital stationery does not have to remain as fragmented and duplicated as it is today, with different files for KOffice and OOo; OpenDocument makes all that obsolete. Therefore, I hope that all contributors and GNU/Linux packagers of this material will cooperate to make it immediately usable by any application that needs it.
