Package partitioning?

["Karsten M. Self" <kmself@ix.netcom.com>]

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