On Wed, Jul 17, 2002 at 11:28:16AM -0400, Kevin B. Hendricks wrote:
> There just has to be a better way than having every distribution and OOo
> itself doing something different which will make support and upkeep
> unmanageable.
Well, not unmanageable, just making the packagers to all produce the same
work and duplicate it among themselves ;)
> 1. Where exactly under Linux should OpenOffice.org be installed? Are there
> official guidelines? Is this /opt or /usr/bin or what? Does this differ
> from distribution to distribution?
Thankfully, the Filesystem Hierarchy Standard [1], as part of the Linux
Standard Base, is the basis for the majority of the distributions. Making
it possible to install OOo according to the FHS would be of great benefit.
For packages supplied with the distros, the layout would be under the /usr
hierarchy. A package that is not seen as part of the distro would have a
similar layout, but under /opt instead. Users may wish to continue
unpacking the tarball under /usr/local, too.
> What about other Unix (Solaris, FreeBSD, MacOSX, etc?
I think following the FHS would work in almost all cases.
> 2. More specifically, where should all of the pieces of OpenOffice.org be
> installed? Are there specific directories ... /usr/share/ and /etc/ ...
> that we could all agree on and what goes there.
>
> To help guide this discussion, could you tell me where you put the various
> pieces of OOo in your latest Debian versions (including workstation
> pieces)? Perhaps someone from Mandrake could add their info as well. I
> heard that OOo was part of the alpha RedHat releases as well. Does anyone
> know where they are placing the pieces.
Currently, we are placing the complete hierarchy as intact as possible under
/usr/lib/openoffice. Normally this directory would only contain
architecture-specific files, but we have tried to avoid changing more than
is necessary.
The files which we do already move are:
/usr/bin - user binaries. Debian and Mandrake (and possibly others) have
commands in here such as openoffice, oocalc, oowriter, ..., oospadmin.
/etc/openoffice - global configuration. I have placed the workstation
autoresponse file here and dictionary.lst, psprint.conf and sofficerc,
with links in the places where OOo normally expects to find them. In this
way, sysadmin changes are preserved across upgrades, and the sysadmin
can find the OOo configuration files easily.
Desktop integration. I'm not sure I've got the Gnome path right yet:
openoffice/share/kde/net/mimelnk/share/icons -> usr/share
openoffice/share/kde/net/mimelnk/share/mimelnk/application -> usr/share/mimelnk
openoffice/share/kde/net/applnk -> usr/share
openoffice/share/gnome/net -> usr/share/gnome/apps
We add these files:
+ Extra manpages in /usr/share/man. These are only just written
(yesterday), so they are not yet ready for us to send for inclusion!
+ The wrapper in /usr/bin/openoffice that autoinstalls and changes the user
interface language on the fly
+ Extra menu entries for the systemwide menu system
+ Entries for /etc/mailcap
+ A Debian-specific README and TODO
+ A workstation install autoresponse file.
That's it for the moment. Ideally the non-architecture dependent files
should be under /usr/share/openoffice rather than /usr/lib/...
Also, the documentation should be installed under /usr/share/doc/openoffice,
rather than being copied multiple times within the user hierarchy.
We modify the workstation setup to place the ~/OpenOffice.org1.0.1 directory
under ~/.openoffice/1.0.1. This prevents cluttering of the user directory,
and is consistent with most other software.
> 3. What additional pieces would augment or help OOo under Linux (and other
> Unixes)?
>
> - fonts - ghostscript urw fonts
> - any ttf free fonts around?
> - templates, HowTo's etc
>
> How / where would these be installed?
Those would all help, and more too. Generally, we would create a new
package and install those files according to the FHS for that package.
However, files like dictionaries, which need to all be installed in the same
dictionary, would depend on the openoffice package and join its already
installed dictionaries in the same directory.
>
> 4. How does Debian currently handle localizations for languages? it makes
> no sense for people to have to download a German build, an English build,
> etc. People should be able to post install all localizations, shouldn't
> they?
Absolutely. We actually have a way now to install the localisations
seperately, although it is still hackish in places. The packages are split
into common packages (the openoffice binaries and support files), and
language-specific packages. It works like this:
- The build is generated for all languages. This creates 1.7GB of
installation sets, my complete build tree ends up being about 5GB in
total :(
- The openoffice.org and openoffice.org-bin (non-arch and arch packages)
are created from the English install set, by running a network setup
into a temporary directory.
- The language files are unpacked from the installation sets by looking at
the instdb.ins for each set, and made into openoffice.org-l10n-<lang>
packages.
- At runtime, we have a wrapper which is run before starting soffice.
This wrapper performs a workstation autoinstall if necessary, then
checks the user's locale variables for the language. If the language is
different, it edits the user's Linguistic.xml and Setup.xml to change
the language, and then OOo is started. The editing is performed in perl
and is only really a hack. See our CVS for the scripts [2].
Really, we don't have need for the packing into all these install sets. The
only part we need is the instdb.ins, to see which files belong to which
language.
> Pehaps we should be splitting installation approaches completely based on
> platforms, WIN users may expect something very simialr to what exists now.
> Mac OSX might want to use a similar graphical approach as well albeit
> looking differently, Linux may want to use dpkg, and rpm based approaches,
> and Solaris, Irix, etc may have different ideas.
Certainly, the ability to have several smaller subtrees in an install would
be a big benefit for the majority of the unix world. I still think there is
a place for the .tar.gz install into a subtree approach, but optional
support for a FHS-type of install would provide big benefits.
> Either way, we need to rethink how installation is done in general and
> perhaps have platform-centric installers built as part of the OOo build
> process.
Possibly, yes. For the case of rpm and deb installs, the installer is built
into the OS anyway (and I guess that holds for Windows, too?), and all we
need is some support for controlling the installation process by scripts.
Something like support for a 'make install' and access to the component
registration process would make our lives a lot easier, and allow us to
provide more modular installs.
I hope these rather Debian-centric thoughts are useful :)
Chris
--
[1] http://www.pathname.com/fhs/
[2] http://cvs.debian.org/oo-deb/debian/?cvsroot=debian-openoffice
Attachment:
pgpxkIRJ8iXZi.pgp
Description: PGP signature