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

Re: openoffice.org_1.0.1-5_i386.changes REJECTED



Hi James,

On Sat, Sep 21, 2002 at 12:18:25PM -0400, James Troup wrote:
>  Sorry for the delay in processing this package.  Please split the l10n
>  debs and any other arch: all deb and their source out from the main
>  package.  If you don't do this, everytime you want to make any change
>  to the source package you'll have to upload all the l10n debs again,
>  even if their content is unchanged.  This is a really excessive and
>  gratuitous mirror hit which is easily avoided and there's no
>  compelling reasons not to AFAICS (e.g. you're already not using
>  pristine upstream source because you remove some non-free parts).

I fully agree with you that the current system is not particularly bandwidth
or mirror friendly, and had such a split been easy it would have been done
already.  We've spent a few days thinking about this and are now not sure
which option to pursue:

There are .src files in OOO, that are used to generate: a) resources
files with translations b) header files with keys that are used by the
program to access these resources. So splitting these .src files from
the OpenOffice.Org source is not like splitting them from the binary.
Upstream doesn't actually split anything; they just make a complete install
.tar.gz for every language :-/

The project splits more easily if it is split into its component CVS
projects.  It is already on our todo list but there is quite a lot to do:

  - Change the build system to work without having write access to the
    staging area where all components are installed before building the
    custom installer, which unpacks files as well as registering components
    and making initial configs.
  - Make and maintain packaging for each project (there are 104, so we'll
    have to combine several together).
  - Prevent the creation of installation sets by the custom installer.
  - Split the installer to prevent file copying and only do component
    registration/config.

The OOo team is small (3-5 part time volunteers, and only 2 are actually
building complete packages), and we need as much support as we can from
upstream.  We're trying to keep the Debian-specific patches to a minimum so
that they are willing to support user problems directly.  The .orig.tar.gz
only has 1 change in 37000 files; the split that you suggested would touch a
lot more.

Ways in which we could proceed (listed in order of preference) are:

1. Leave the packages as they are for now.  We will minimise mirror impact
   by only uploading occasionally, making sure sure that changes have had
   some testing to make sure that they will not need to be immediately
   replaced due to breakage.  We will continue to work on a per-project
   split for the long term.

2. Create two source packages: openoffice.org and openoffice.org-lang, which
   would have the same .orig.tar sources, but perform separate builds.  This
   hits the archive with an extra 130MB source tarball but reduces
   subsequent package updates that do not involve a new upstream.

3. Do the split by project before uploading.  This is the way we'll go in
   the long term, but it will take us several months to get ready.

4. Something else?

What would you suggest we do?

Thanks,
Chris



Reply to: