Nicolas Mailhot wrote: > Le dimanche 24 avril 2005 � 23:59 +0200, Mathias Bauer a �crit : > >> I don't know if it is system-update proof, because I don't know what >> that means. If you could describe it maybe we can find out if this >> applies to the OOo Add-On installer. > > It means in 2-3 years I can take a Linux system, issue the system update > command (yum -y update for example) and everything will be updated at > the last version without human intervention. Try to achieve this with > your system
I don't see a problem with OOo Add-Ons in this scenario because the OOo strategy is that Add-Ons created for version X will still run with version XX 3 years later because the API is kept compatible and the whole deployment process is under complete control of OOo itself. Of course the Add-On will not be updated to the latest version, but at least this is not necessary to keep it running. In fact I have done this already (and I already mentioned it some days ago on this list): an Add-On written years ago still runs with the latest OOo build. So the question is: yes, the Add-On is not updated to the latest version. But my question is: why do I need to do that? If the version I have also runs with the updated version of OOo it's OK for me! Besides that I don't see a problem in combining the Add-On installer with system tools, but until now we didn't feel the need. If people want to work together with us making this happen - why not? But until now I didn't see helpful comments, only useless complaints. Anyway, deploying Add-Ons as an RPM or so that uses a post install script shouldn't be a big deal. But here we face the problem that not even on Linux there is a universal package format and on Windows you don't have anything like this (yes, the majority of our users still uses Windows, like it or not). And you can't expect that every simple developer that wants to let other users use his macros or Java programs to make their life easier will create packages for all the distributions in the world and additionally provides an msi file for Windows, so we need a way to deploy this in a platform independent way. Following your advice we must disable saving Macros in our BasicIDE and create system packages only, because there is *no* fundamental difference between a macro library and a maro package stored in your user directory. To me that sounds like a very bad idea. >> BTW: do you know the OOo Add-On installer at all and the way it works? > > Don't know and don't care. OK. You complain about something you don't know. You don't listen to arguments from others. You think you know everything better and so you don't need to learn and understand. And you want me to take you serious? Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
