Hi Laurent,
the problem with running any executables you are just about to install
(like unopkg) is that you enforce the runtime dependencies to be
fulfilled at installation time, which can be a problem for people that
bundle OOo with an operating system.
However, for optional packages, it should be possible to add support for
running unopkg in some postinstall process/script (I believe currently
there is none). There is also the option to just provide a skeleton for
native packaging - without further OOo integration.
Another option would be to develop a script that transfers a UNO package
into a structure that does not need unopkg calls and run it during the
packaging process, but this would basically mean it is no longer an
extension ;-).
Regards,
Oliver
Laurent Godard wrote:
Hi
I'm actually thinking to the extensions project through the DicOOo
porting work.
The purpose is to provide DicOOo, or any future valuable extension, at
source level so that it can be delivered within OOo and share the
translation mechanisms
Generally, people who wrote an addon package, in any UNO supported
language, do not care about OOo sources internal organization and it
will be difficult to ask them to transforms deeply their code to
integrate OOo
A solution would be to provide them with best practices and common
framework (one of the extensions project purpose) and deploy as an
addon. The sources could be unpacked inside the cvs and built from
scratch. This would also allow to integrate the translation process
So the question
Is it possible to deploy addons at OOo installation level (so, running
unopkg) ? if yes, some pointers are welcommed
If no, what prevent this ?
IMHO, allowing Uno packages deployement at installation level will
lighten the integration process
Thanks in advance for your response
Laurent
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
