[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: buildd machines vs. resource-hungry packages (ITK)

On 17/09/2011 16:17, Steve M. Robbins wrote:
> So after sending this, I think I have hit upon a solution by 
> splitting into multiple source packages.
> It seems that the wrapping can be done by using the installed headers
> and libraries.  So I can have the core source package build only the
> C++ libraries and also install the cmake files for wrapping (to
> /usr/src/WrapITK).  Then I can create three new source packages, say:
> wraptitk-python, wraptitk-tcl, wraptitk-java that build-depends on the
> ITK -dev package (which provides /usr/src/WrapITK).  Each wrapping
> package builds just one set of wrappers so the disc usage is only a
> third (maybe 3-4 GB if I don't use -g).

Looking at amd64, the Installed-Size of current packages are:
insighttoolkit3-examples 3888
libinsighttoolkit3.20 12964
libinsighttoolkit3-dev 26808
libinsighttoolkit3-java 41740
libinsighttoolkit3-jni 227656
python-insighttoolkit3 556020
tcl8.5-insighttoolkit3 377112

The first one is small. The second and third will be required (as
build-dependencies) to build the following ones.
  The four last ones (the bindings) are about 1.2GB big. The biggest one
is 550MB big. It means that, on amd64, you will save at most 700GB but
your build system will be a lot more complicated (with multiple
inter-dependent uploads).

  If you think that 700GB saving is not enough to split your package,
you can work on the build of your actual package to remove intermediate
built files between each parts.
  I mean that you probably do something like ./configure ; make ; make
install ; dh_install ; ...
  Perhaps, you should tried to modify your build system to do
./configure --only-corelibs ; make ; make install ;
 dh_install -pcorelibs
make clean
./configure --only-python-wrapper --with-corelibs debian/corelibs/...
make ; make install ; dh_ionstall -ppython-bindings
make clean
./configure --only-java-wrapper ...
and so on
(package names and configure options are only examples to give you the
idea, I do not know at all how your package is build)

  The idea here is that (the size required when building from one source
package) should be roughly equivalent to (max for each source package of
the required size) + (the size of all binary packages)


Vincent Danjean       GPG key ID 0x9D025E87         vdanjean@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Reply to: