Nicolas Mailhot wrote: > If this means OO.o internals map well to Linux packages needs and you're > ready to work with me on making native packages happen let's do it.
I think we could think about this doing by ourselves as soon as the major Linux distros have standardized on a common "native" format. Until then IMHO it's the job of the distros to provide the packages if they don't want to use the "OOo format" for Add-Ons. Of course we can work together with them to bring this directly to the users (means: enable our SDK to create those packages directly), but we never will "standardize" on any of those formats as long as there are many of them, so we will always use our own format by default or as a fallback. > If this means you can do the same thing via platform-independent OO.o > bundles and argue there is no functional advantage going the native > route then sorry, it got about the same appeal as a if you proposed to > me to use a separate phone per correspondant because it's too bothersome > for you to use the same hardware as the other links. And I'd agree with > you all the different telephones are functionally equivalent except I'd > like to keep some room in my pockets for something else so that's not > really the point. Of course there is a functional advantage going the native route, but the question is as always: is this advantage achievable at a justifiable cost and do the things you lose not doing it this way really create a problem? If the only advantage of doing it the native way is that it is done the native way, I see it as a dispensable advantage. OTOH if the non-native way creates a demonstrable problem this must be solved, and if the only way to solve it is doing it the native way then this is the way to go. But I'm still waiting for a demonstration where our installer creates such a problem. > The point is to keep a _single_ software/app/lib database per system, > with a _single_ key/certificate repository, a _single_ update model and > a _single_ point of entry for users. I understand that this is desirable in an ideal world, but this makes platform independent development extremely difficult if not impossible, especially if even a single platform (Linux) is not able to provide a standardized way to do things. It's hard enough to support both Windows and Linux! And no, we will not give up Windows and we never will support only a single Linux distribution. IMHO your standpoint it too strict. You see the single software database as a value per se, I only see it as a means to and end (I see everything this way BTW ;-)) and it's only the end (here: the administration) I care for, not necessarily particular means also. > And you can argue OO.o is special and should be an exception except > every app writers feels his app is special and wants the very same > exception so that's a direct way to system management hell (be it for > single-user systems of big centrally-managed computer pools) That misses the point. The specific characteristic of OOo arises from its platform independent nature and the pure fact that we can't offer support for every package format on this planet. Do you remember the complaints that OOo "only" offers RPMs? What do you think will potential Add-On developers say if you force them the provide native installation support for all platforms? Yes, we won't get any development in this area and we see this as an important entry point for developers, so we want to enable people to create such Add-Ons. If you or any other people are interested in working on the support for a particular package format and if you are willing to help us implementing this you will be welcomed ony our dev@udk.openoffice.org mailing list. 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]
