I followed some of the packaging discussion on deb-user, apologies if this has already been covered. What is current thinking on how OO should be packaged? I don't think that one large package would be either practical or desireable. I've followed StarOffice, that bloated stuck pig of an office suite [1], & OpenOffice discussions for a while, and my understanding is that the OO folk actively *want* to segement the suite into its constituent components. I've also discussed the issue with Brian Behlendorf (Collab.net hosts the OO dev site), and discussed the pragmatic problem of being involved in development or debug of a tool whose size grossly precludes my either storing (on my primary desktop: 6GB total storage) or downloading (~650MB over a 56kbps line is about fifty hours of download time) the suite in its current state. The build and development environments are Just Too Big®, and this is a Bad Thing®. IMVAO, package development, let alone use, is going to be greatly facilitated by splitting this monster up into constituent pieces. It's also possible that practical use of the OO data format interchange libraries [2] would be made far easier. I can't admit to any great understanding of the OO codebase. Seems however that packages might be divvied up as follows: Collectively: openoffice-apps, with deps of: openoffice-scalc openoffice-smaster openoffice-soffice openoffice-sweb openoffice-sdraw openoffice-simpress openoffice-smath openoffice-swriter ...and for commonly used components: openoffice-common Note that currently all these programs but soffice are merely shell scripts invoking soffice with a specified personality. soffice itself is a shell script to invoke soffice.bin. So it would make sense to find out whether or not a further subsetting of components is anticipated. Assuming these components can be subset, subsetting libraries would be helpful: openoffice-scalclib openoffice-smasterlib openoffice-sofficelib openoffice-sweblib openoffice-sdrawlib openoffice-simpresslib openoffice-smathlib openoffice-swriterlib ...and for commonly used libraries: openoffice-lib To the extent that various conversion libraries could be singled out, they would be seperated from the above, listed as deps, and we'd have a set of document conversion libraries: Collectively: openoffice-libfileformats: openoffice-libfile-common openoffice-libfilemsft openoffice-libfilemsft-word openoffice-libfilemsft-excel openoffice-libfilemsft-ppt openoffice-libfilemsft-access openoffice-libfilemsft-etc openoffice-libfilemsft-common openoffice-libfilecorel . . . Again, this is something of an ideal division, it may not be reflected in the current code structure of OO. Informed comment welcomed. -------------------- Notes: 1. Yes, my biases are showing, and yes, it's a vim abbreviation expansion ;-) 2. Multiple people have identified these as the truly valuable components of StarOffice/OpenOffice. Making MS Office format interchange libraries a basic component of GNU/Linux would be a powerful advantage. Liberating these from the Bloatedness That Is OO would be a Good Thing®. E.g.: these libraries would be commonly available to tools such as catdoc, antiword, doc2foo, AbiWord, KOffice, and, natch, OO. -- Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/ What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org Free Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org Geek for Hire http://kmself.home.netcom.com/resume.html
Attachment:
pgpx67HGNWspR.pgp
Description: PGP signature