Re: Desktop integration for distributions [was debian-openoffice Announcing OpenOffice.org 1.0.1]
Hi Chris,
Thanks for your reply.
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.
Let's think about the very basics for a second (go back to first
principles) and see if there is some common ground we can use:
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?
What about other Unix (Solaris, FreeBSD, MacOSX, etc?
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.
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?
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?
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.
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.
Comments, Ideas, rants, and Raves all welcome?
Hamburg developers, what are your long term plans for installation
approaches?
What do people think?
Kevin
On July 17, 2002 10:49, Chris Halls wrote:
> On Wed, Jul 17, 2002 at 08:04:32AM -0400, Kevin B. Hendricks wrote:
> [quoting my announcement of upcoming .deb packages for OOo 1.0.1]
>
> > > These will include the desktop
> > > integration, which is now complete for KDE and possibly for Gnome
> > > (but untested).
> >
> > Are the above in any form to be contributed back to OOo? I would love
> > to fix desktop integration for all distributions.
>
> I wish I could say otherwise, but unfortunately the changes I made all
> take place after the network install is complete and the .deb is built.
> There are a number of issues with the original install which make it
> difficult for me to provide changes that are useful unless decisions are
> made to change the way things are done, and that would probably
> modifications to the build system. I'll list them here and my thoughts
> about them aaybe we can come up with a solution that helps everyone.
>
> 1. The network install is all to one subtree.
>
> I fully understand that there are good reasons for doing this (keeping
> all files together, making them easy to manage, allowing co-existing
> versions, OS-independent layout etc.), but when building packages that
> use the OS's package tools such as dpkg or rpm that integrate tightly
> with the rest of the system, we need to place files in different places.
> For example, to get the desktop icons and shortcuts working for KDE, I
> performed a network install to a temporary directory and then moved the
> subtrees around:
>
> share/kde/net/mimelnk/share/icons -> usr/share
> share/kde/net/mimelnk/share/mimelnk/application -> usr/share/mimelnk
> share/kde/net/applnk -> usr/share
>
> After that I used sed to edit the pathnames in the shortcuts to point to
> the right places.
>
> The only solution I can think of at the moment is for some extra options
> to configure, such as --with-kde-path and --with-gnome-path or something
> similar, which can be specified at package build time to allow placement
> of these files outside of the main install tree.
>
> 2. There are only two options for the desktop integration: on or off.
>
> Our very first packages used the 'on' option: The files were installed
> in central locations but also copied to every user's home directory.
> This is unecessary if a central install has been performed well, and the
> integration is already available centrally. We often had users being
> confused by error messages where files could not be copied to ~/.kde2
> (The Debian default is ~/.kde) or ~/gnome, and the files would be left
> behind if the user uninstalled the network install without first running
> setup in their home directory. After that I switched to 'off', where
> the files were not available at all, and the users' complaints changed
> from 'what are all these file copy errors' to 'where have the menu
> entries gone'. Gwenole Beauchesne at Mandrake came up with the idea to
> set INSTALLED=NO in instdb.ins using perl after the network install was
> complete. But that is really a hack and needs do be an install option
> so that anyone who performs a network install can enable central
> integration but disable the modifications to the users' home directory.
>
> There has been discussion about this at Issue #6218.
>
> 3. The icons are delivered as xpms, but KDE/Gnome expect pngs.
>
> In fact, xpms can still be used but support is likely to be dropped at
> some point.
>
> > Also, there is some talk upstream of building a generic GPL installer
> > that will be run automatically after OOo official install is complete
> > and install lots of dictionaries, fonts, templates, how-tos,
> > hyphenation dictionaries, thesauri (or is that thesauruses?) and even
> > handle desktop integration and allow users to select themes or icon
> > sets. and etc. It will be able to download all components from the
> > web or use local storage (harddisk or cdrom).
> >
> > The basis for this already exists in the form of the current
> > dictionary autoinstallers.
> >
> > Is there any interest from Debian in getting involved in such a
> > project? Would it help or hurt your efforts?
>
> I'm afraid that a large part of the functionality would be redundant for
> distribution .deb and .rpm packagers. We already have a centralised,
> systemwide way of downloading and installing extra software, with all of
> the infrastructure needed to support mirroring, upgrades, version
> compatibility etc. The only part which I can see being of interest is
> the way in which the installed module is made available to the users.
> But the new central dictionary system in OOo, even this is trivial to do
> with a simple perl script that adds the appropriate line to the central
> dictionary.lst. Rene Engelhard made packages for the German
> dictionaries, so he may be in a better position to comment. If the
> installer could be used in a scripted update-configuration mode, it may
> be useful nonetheless.
>
> Generally, you only tend to see installers packaged up for Debian if the
> installed software is not freely distributable (such as the MS truetype
> fonts or realplayer), or changes so quickly that the packagers and/or
> infrastructure can't keep up (such as virus updates).
>
> If this generic installer ends up being able to install a very large
> amount of extra functionality, it may be worth packaging it, but that
> would mean that users wanting to install these extra modules would have
> to go online for these extra packages, at which point we'd probably say
> the modules should be packaged as .debs so that they can be properly
> included in the Debian distribution, including on CDs.
>
> Of course, I'm looking at this from the point of view of systemwide
> packages being installed in a way that makes them available to all users
> on a system. Or will the generic installer focus more on per-user
> installs?
>
> Chris
--
To UNSUBSCRIBE, email to debian-openoffice-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: