On Mon, May 13, 2002 at 10:09:42AM +0100, John M Cooper wrote:
Its huge! over 60 Mb for each platform! We have already put 130Mb plus
source into the archive!
I suggest 3 splits
openoffice.org
openoffice.org-doc
openoffice.org-common
openoffice.org-gallery
Have a look at the list of modules generated by setup, which I have put up
at
http://www.mx1.ru/~chris/script.htm
It gives you an idea of the sizes of the components available, and how
upstream modularisation works. You can work out which files are installed
by which component by editing the Set1 line in
debian/local/rsfile.global.txt, removing the modules you are interested in
and comparing the generated MANIFEST.new with the MANIFEST file in the
package.
The repackaging HOWTO [1] recommends a split like this:
To split the file list into two, you should include all files in
<path-to-openoffice-root>/program/resource and the
<path-to-openoffice-root>/share tree into the language package list and
the rest into the binary package list.
openoffice.org is the main package that contains the platform dependant
files it depends on OOo-common and recommends OOo-doc and OOo-gallery
OOo-doc is the docs ;-) this is basically the help files split out.
OOo-gallery is the clipart and backgrounds but not the applications
OOo-common is the rest! All platform independent
Other options could be OOo-printers containing all the printer drivers
and OOo-templates with all the templates, OOo-java containing the java
files.
Part of the setup process includes registration of installed components. It
is not always enough simply to split files out into an optional .deb and
expect the feature to be enabled/disabled by having the .deb around or not.
For example, Martin told me he unpacked the French language files into
<ooroot>/program/resource, with no effect - setup must be run to enable
these files. We'll have to test to see if simply moving out help files and
gallery files works as expected.
I discovered that a simple file-removal did not work for Java - at
build/install time I have Java available, but if I use
Java=preinstalled_or_none in the setup response file, setup will not run if
Java is not installed - that's why I set it to none. I guess we may end up
with similar problems for other components.
What does everybody think? I dont think that we want to split it up to
much but getting some of the bulkier items into separate downloads that
are both common across all platforms and dont need to be downloaded
every update could help I think. Then we could do OOo_1.0-5 depends on
OOo-common >= 1.00-3.
Yes, splitting these up will prevent such large downloads on update (that
is, provided the packagers are willing to spend the time working out which
package has really changed and should be uploaded - I don't know that this
can be automated), and I don't think we'll be able to make all of the
seperate .debs optional without additional further work.
If we can agree what is needed then I will look into it further.
I think this will end up being a bit of a trial-and-error process at first.
Thanks for looking into it.