Hi,
Nicolas Mailhot wrote:
Joerg Barfurth a Ãcrit :
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.
This is what I feared.
Of course you can tell rpm (and probably deb) to invoke some random command and ignore the resulting files.
But you loose all the integrity properties of a proper rpm install and these files are where problems occur in practice.
Here you effectively have a two-tiered integrity architecture. The system package manager takes care of the system as a whole, viewing UNO packages as opaque files. The UNO package manager takes care of the integrity of the UNO environment which involves looking at the content of the UNO packages and knowing about things like UNO service registries.
BTW: Stuff like service (daemon) registration is often a weak spot of Linux package management. This is an area where distros differ in tools, conventions and file organization, so third-party packages may easily get it wrong. Even Solaris only now has a really strong solution for this. And probably one of the reasons is that this involves manipulating resources that must (by their nature) be shared between packages. The OOo UNO installer takes care of these issues for UNO packages in a cross-platform, but UNO-specific way.
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?
I can do fun stuff like [SNIP]
Or just do a simple
%setup
if stuff is provided in a clear archive that uses common conventions
For UNO packages that really is up to the package author. The UNO package manager only takes care of the installation side of native packages. The automated-build part is not addressed by this at all.
Of course most add-ons ought to be built using our SDK. So doing this part properly for native packagers means creating ooo-devel and/or uno-devel packages from our SDK and to make the SDK support or encourage rpm/deb-friendly ways of building.
Kills checksums2. 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
Means a file belong to several packages and no one has the right to fix it
The same applies to any place in the system, where information from multiple packages needs to be joined to coordinate their functions.
The UNO package manager does keep unaltered copies of the (packed) UNO packages, which clearly belong to the wrapping native packages and can be checksummed. The 'cache' area where the contents of the UNO package files are unpacked and merged files are created is owned exclusively by the UNO package manager. But it is true that a native package manager can't know which of these files depend on what UNO package and in what way, so checking or restoring the integrity of this data must be done by invoking the UNO package manager.
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.
Do you have a canonical place for UNO packages ?
The UNO package manager maintains its own repository of unaltered copies of the installed UNO packages. Usually UNO packages installed using 'unopkg add' are copied to that location. Maybe it is possible to let native package managers install files directly to that location to avoid having multiple redundant UNO package repositories on the system.
ie can someone do something like :
1. add new uno sources to canonical place
2. remove cache directory contents
3. execute command that will regenerate it _without_ providing new UNO sources (this part is crucial - if you need to provide sources every time that means every extension package has to know the full installation history)
Not sure what you mean by 'provide sources'? (Copies of) all installed packages are kept unaltered in the 'canonical place', so yes, you can remove the cache directory contents and regenerate it.
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,
You're right there. Though I suppose this cache setup part is the responsability of the core oo.o packager not of the extension packager
This cache location is configured in some OOo configuration file. By default it is all under $prefix)/openoffice*/share/uno_packages, but the configuration file hooks to put it elsewhere are all there. Of course configurations other than our platform-independent default are not really tested or 'supported'.
but it is needed and needs to be generated or updated each time when packages are added.
Not the perfect setup for us :(
Is there a way to deduce at build time what file names will be used in the cache ? This way they can attributed to the original package (even if their content is not known beforehand)
You can know the full pathes of the unopkg-owned files where data from multiple packages is merged. Of course you know the names of the files from the unpacked packages. But you can't know their full location, because they are placed in a parent directory with a pseudo-random name. This is new in OOo 2.0 and afaik is needed primarily for the live-install support for user-level packages. Still, it is also applied to system-wide/installation-wide packages.
Do you have per-extension configuration files ?
No. But in a way we don't have (systemwide) configuration files at all.
We have configuration files containing 'factory defaults', but none of them really should be manipulated by administrators, because of various fallacies. So nothing that is currently in $prefix/openoffice*/share/registry/ belongs under /etc.
Extensions may have their own default configuration files to integrate with the OOo configuration system. But these files are only used to generate a file containing merged (and possibly even patched) data in the unopkg cache. This merged file is then read at runtime. Manipulating the per-extension default files or the merged files is not a good idea. When the merged file or the entire cache is regenerated by the package manager, the changes will be lost.
It is possible, but not part of the current standard configuration of OOo, to configure a configuration data layer that can be used by administrators to customize the OOo default settings. If done properly this same layer (a layer is a directory tree, not a file) can also be used to customize defaults for extension packages, but not separate from core ooo or other extensions. If that separation is desired it can be set up as well, but then things get harder to document and understand.
That's another special file we need to take care of because : 1. they need to go somewhere in /etc
You'd need to add them to configmgrrc yourself.
2. rpm must mark them to try real hard not to kill them on updates
They should be left empty by the initial install, so the packages should have no business updating them.
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]
