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
Attachment:
pgpBY0lY4SOC3.pgp
Description: PGP signature