forwarded from the extensions list to discuss only on one list
--- Begin Message ---
forwarded from the extensions list to discuss only on one list
--- Begin Message ---
Laurent Godard wrote:
Hi Oliver,
Thanks for your response
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.
the easiest way, IMHO, would be to register user-level extensions when
first starting OOo for this user at licence egreement
But the problem is for shared packages (the most used cases in fact)
I am not sure if shared packages are installed more often. But anyway it
is more or less the same problem. A package gets installed and when a
license agreement is necessary the user will be asked. If the user
denies the agreement the package is disabled for the user.
For this scenarios we have a detailed spec (draft not online available
yet). I think we should make it available for review asap.
But we still have the problem with packages which should come with the
office directly. I have the feeling that this late init or registering
at first start up does not scale for a huge amount of extensions.
Conversion of extensions into native installer packages is one solution
but it needs some further extension of the whole deployment process.
But native installers have the drawback that they are platform
dependent. Maybe we find a better way to integrate smart in the normal
office installation process.
We have plans to improve the deployment and make it more static, plus
versioning, plus defining and checking dependencies, online update, ...
Especially the last improvements makes it probably obsolete for a lot of
extensions to get installed with the office directly.
And even if the community decides to integrate some features in the base
installation, it would be possible to integrate them in the normal
source tree and build process. This should be the default for all final
extensions to ensure frequently QA on the master.
Third party extensions should be deployed over the package manager and
ideally the user get noticed if updates are available (see for example
firefox extensions).
Juergen
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 ;-).
Agree
But i think that the "distrib/packager" specific issues have to be
handled by them
If they want to add an extension, then lets split
we can perharps provide some tools to help them
but should not be our default use
OOo has a great and promising package framework
OOo is multiplateform and can not endorse sepcific deployers problems
Obviously, i'm opened to discussions :-)
My concern is to make things easy to enrich OOo
Laurent
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- End Message ---
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- End Message ---
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
