Nicolas Mailhot wrote: > Java is platform-independant and it still is packaged natively (in fact > the only inroads java made linux-side recently is when Red Hat started > providing native packages) > > Perl/python are somehow platform independant (certainly a large part of > the perl/python apps can be used without platform-specific builds) and > they are still packaged natively. Perl already offers its own deployment > system and it si not used except by Perl developpers
That's right, and as we all know OOo will also be packaged natively starting with OOo2.0. But to support all developers that either don't want or can't do this for their OOo Add-Ons or components OOo has its own packages for UNO components. If distributors feel the need to create packages in *their* own format we can try to support them, but we won't do it by ourselves. Obviously you follow the same approach, so we start to reconcile to each other. Nice. :-) As an example, our package is just a zip file and you need a single command to install it (either into your installation our into your profile). Our graphical installer just uses the same command line to install (or remove) the package. It isn't a big problem to create another package (let's say an RPM) containing the zip file and to use a postinstall script for the execution of the OOo installer command. Maybe you have something else in mind?! > You don't have to do the whole thing at the OO.o level. I've already > outlined in the previously quoted message the common elements that could > be done at the OO.o level and how to interface with distributions so they > do the last mile. A lot of stuff can and should be taken in charge by OO.o > directly Hm, maybe I don't understand you, but I can't find anything that I can recognize as "common elements that could be done on the OOo level" in this mail. Or did I look into the wrong mail?! If you pointed us to some kind of requirements we could see if we can meet them. > And by not providing native packages I don't necessarily mean not > providing native packages at the OO.o level but not creating an > environment where other people can easily provide them. Fine, why didn't you mention this in the first place? Would have saved us a lot of time. :-) I hope my small example goes into the direction you have in mind. If this turns out to be the way you want us to work together I'm very interested in getting this done as soon as possible, just because we want to emphasize the Add-On development a bit more in the future and so it would be fine to clarify everything upfront. 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]
