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.
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.
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
=============
%prep
rm -rf $RPM_BUILD_DIR/%{toplevel_dir}
export MORE=10000
sh %{SOURCE0} <<EOF >/dev/null
yes
EOF
%setup -T -D -n %{toplevel_dir}
chmod -R go=u-w *
chmod -R u+w *%ifnarch x86_64
# make sure the plugin exists
_OJI_PLUGIN=$(echo %pluginname | sed 's|%{_jvmdir}/%{jredir}|jre|')
if [ ! -f $_OJI_PLUGIN ]; then
exit 1
fi
%endif
==============Or just do a simple
%setup
if stuff is provided in a clear archive that uses common conventions
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
Kills checksums Means a file belong to several packages and no one has the right to fix it
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 ?
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)
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
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)
Do you have per-extension configuration files ? That's another special file we need to take care of because : 1. they need to go somewhere in /etc 2. rpm must mark them to try real hard not to kill them on updates
Regards,
-- Nicolas Mailhot
signature.asc
Description: OpenPGP digital signature
