Hi Grigor,
Grigor Gatchev wrote:
Hi Pavel,
You sent this mail to the [email protected] mailing list, not to Pavel. This is fine: in general mails of this kind should go to the mailing lists, not to individuals. But this particular topic is probably best suited to the [email protected] list.
You also should consider subscribing to the lists you post to. Most replies go to the list only, so you won't get them.
I'll forward this mail to the [EMAIL PROTECTED] list, so the installation developers can see it.
I tried to install from the 1.9.81 .deb packages, and met some minor problems.
The deb packages are not distributed by openoffice.org proper, so we may not be able to help you with all of these problems.
Please keep in mind that Pavel's milestone builds are really intended for developer/localizer type people. AFAIK they are not really intended for end users or production use.
To start with, the old 1.1.3 OOo version was not removed. Which was good, since nothing was installed, too.
The old version is not supposed to be removed when 1.9.x is installed.
Curious about the reasons, I took a look on the packages themselves, and noticed the following (I'm not a .deb guru at all, and surely have missed a lot of things):
Dependencies: Most of the packages depended on the core01 package - and only on it. I doubt that this is the real situation - at least, core01 should have depended on the other core packages, if they are ever needed. Also, the language pack depends on no other package (and I don't believe it is of much use just by itself).
This is a known problem (sorry I don't have an issue id at hand).
The language packs probably should depend on the core01 package as well. But afaik the language packs distributed by openoffice.org work differently: They are wrapped by a script which finds out to what prefix OOo had been installed, so they can be installed to the same prefix. Because of this they have an implicit dependency on an installed OpenOffice.org (core).
Package internals: While the packages appeared to be created in a proper way (with the dpkg-dev tools), they missed most of the info they would need to work. I noticed the following problems, listed by .deb control files:
The deb packages you used, as well as the RPM packages distributed on the OpenOffice.org site are created from a common source using the epm package creator. This tool uses the native packaging tools (dpkg, rpmbuild) only as backends for the actual packaging. Additionally the primary target of initial development has been RPM. Because of this some features that are specific to a packaging system (particularly one that isn't RPM) may not be supported.
control: This is the main control file of a debian package. Mandatory. In these packages, it is present, but misses most of the needed fields. Any control file from a Debian OOo 1.1.3 deb package would be a good example what must be written in here.
I am sure that ultimately Debian will do a fully debianized version of OOo 2.0 that uses the Debian build process and build environment and that has deb packages with all bells and whistles. A largely distro/packager-neutral build system as OOo does not know about 'needed fields' automatically.
conffiles: Expected to contain a list of the OOo global configuration files (these that are installed by this package). Currently empty (does OOo 2.0 packages install config files at all? ;-)
It does, but that is a missing feature of our cross-platform package description system. Files aren't properly marked as conf- of doc- files for RPM either. I pointed this out to the primary installation developer a while ago. AFAIK we do plan to add that feature, but I doubt it can be done in time for OOo 2.0.
shlibs: Expected to contain a list of the shared libs installed by the package. Not present in any of the packages I looked in. Theoretically not needed, if OOo doesn't install any shared libs; I have the feeling, however, that it does.
It does. But it does install them to a private location, so they are not intended to be shared with other products. I don't know the exact purpose of this deb field - and RPM does not flag shared libs in special ways. Is this really needed?
preinst: Usually a shell script. Expected to prepare the things for the unpacking of the archive tree and files (eg. create needed dirs, backup important stuff etc.) Optional, but typically needed. Currently missing.
AFAIK we currently don't have any preinst scripts.
postinst: Usually a shell script. Expected to do homework after the system is unpacked (eg. start a daemon after installing it). Appears to be intended for RPMs, not DEBs - that is, it will not work correctly here.
Huh? What is incorrect about the postinst scripts? This could be a epm problem as epm generates these scripts from a packager-neutral source. FYI: we also generate SysV packages for solaris from the same source.
OTOH currently the scripts do some form of system integration only. The office should work without them.
prerm: Usually a shell script. Expected to prepare the system for being removed (eg. to stop a daemon before removing it). Optional, but typically needed. Currently missing. postrm: Usually a shell script. Expected to do cleanup after the package contents is deleted. Appears to be intended for RPMs, not DEBs...
What is the problem?
md5sums: A file, listing the MD5 sums for the files to be installed. Optional, but typically a good idea. Currently missing.
Within the package? If that isn't created by the packager, I doubt we'll do it. We do have posted md5 sums for the files you can download from OpenOffice.org and mirrors.
config: Usually a shell/Perl/Python script. Asks the user questions over the installation details before performing it (sometimes called a preconfiguration). Needed if some details should better be asked to the user. Currently missing.
Our packages don't have to ask anything. The only things you can configure at installation time is the prefix to install to and the choice of packages to install (or not to install).
Typically, a deb package header may contain other needed files, too - templates, etc.
As mentioned: our build system won't produce deb-specific stuff.
Another note: The Debian versions of OOo typically contain a package called openoffice.org-debian-files, which contains all possible differencies between a Debian OOo and any other OOo. Typically, the scripts numbered above would contain references to utilities and procedures inside this package - see the typical Debian OOo package scripts for examples. Some of the things inside this package may be obsolete, but some will probably be needed.
This applies only to the version released by debian itself. AFAIK there isn't such a version yet. If there was, the debian-openoffice mailing list (of the debian project) would be the place to discuss it.
Ciao, Joerg
-- Joerg Barfurth Sun Microsystems - Desktop - Hamburg >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<< Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
