Hi Nicholas,
Nicolas Mailhot wrote:
My (admitedly weak) understanding of how the whole thing should work is :
The UNO package manager does stuff in some ways that really require it to manage its own files and directory on the target machine. Because of this it doen't easily work as you describe.
1. have the uno package source in an archive (archive type and layout needs to be specified to be rpm/deb friendly - rpm for example can digest almost everything but some formats are much easier than others.)
You need that for anything you'd want to install, wouldn't you?
2. at the native package build time, run the oo.o package utility to put things in the right place (needs the buildroot prefix thing I've written about)
The UNO packager manipulates things on a sub-file level and uses an own dynamically generated directory tree to host the manipulated files. It can regenerate this at any time from the original UNO packages - and that is needed for proper uninstallation of UNO packages.
If you need to follow the FHS, you may prefer to put this 'cache' somewhere under /var instead of its current location under $prefix/openoffice*/share/uno_packages, but it is needed and needs to be generated or updated each time when packages are added.
Because of that, at native package build time, you'd only build the UNO package from the source. For this you put the contained product files in their packaging locations and zip them together.
3. the native package install stage is then just extracting these files on the same place on the target system
At native install time you put the entire packages into one location and invoke unopkg from a postinstall script to put the package contents into the proper place in the unopkg-owned 'cache' tree, to merge data into common files and registries and to register the package in the uno package database.
So you only need the oo.o packaging utility at build time, and IMHO for stuff like clipart and templetes that's not OO.o specific you should not even need it there.
OOo does not really have a 'packaging' utility (to package things up you use zip). Instead OOo has a 'package installer', which installs and integrates the contents of such a package into an existing UNO environment. As the package installer is part of the UNO environment, it is available anywhere a UNO component can be used.
it's not so easy and unopkg does a little bit more during installation of UNO packages.
What more does unopkg do during installation ? I thought it would not modify any file not part of the uno package.
It manages data that is wholly owned by the UNO package manager service. Actually any data installed from a UNO package will be used from this cache area, not from any location known in advance.
Ciao, J�rg
-- 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]
