Reboot LibreOffice packaging

Registered by Björn Michaelsen on 2012-09-01

LibreOffice upstream is now almost fully migrated to gbuild. This would allow us to do real partial builds of LibreOffice, with split source packages. There are advantages and disadvantages to such an approach.
Disadvantages:
- More source packages mean more package handling as with an upstream release more source packages need to be build and tested
- testing: most tests require a full libreoffice installation, thus a partial source package cant be tested completely during its build, thus these packages need to be staged in -proposed.
Advantages:
- Bugfixes would be possible without full rebuilds
- Updates can be done without pushing a all libreoffice packages again to all users
- Faster build times as some parts of libreoffice can be build on multiple builds in parallel
- Filesystem limitations on e.g. PPA builders would not hurt us that hard anymore (as the biggest part of the fs-use is objects and dependencies)

And initial proposal would be to have the following eight source packages:
- libreoffice-dev-internal: libreoffice headers
- libreoffice-core: ure and core libraries
- libreoffice-writer, libreoffice-calc, libreoffice-base, libreoffice-impress: applications (impress includes draw, writer includes math) -- these could then build in parallel
- libreoffice-l10n: localization
- libreoffice-common: all the misc. bits and pieces.

And yes, this would require a rewrite of the LibreOffice packaging from scratch -- but that might also simplify things a lot.

Blueprint information

Status:
Not started
Approver:
Jason Warner
Priority:
Low
Drafter:
Björn Michaelsen
Direction:
Approved
Assignee:
Björn Michaelsen
Definition:
Approved
Series goal:
Accepted for raring
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

* [bjoern-michaelsen] check split: does discspace, buildtime distribute equally over the split packages (the core build should be faster (50%) than the monolithic build
* [bjoern-michaelsen] would need to show results by 13.04, and the split packages in 13.10
* [bjoern-michaelsen] the split requires a reoganization of the scp2 upstream component (for all supported platforms). Propose the split for deb/rpm, get buy-in for the other platforms: INPROGRESS
* [bjoern-michaelsen] cross build
  - a mingw cross build is supposed to build
  - identify build-dependencies and make them ready for multiarch
  - check the cross-build, targeting armhf
  - check if the scp2 component is ready for cross-builds, and what needs to be fixed

(?)

Work Items

Work items:
* [bjoern-michaelsen] check split -- does discspace, buildtime distribute equaly over the split packages (the core build should be faster (50%) than the monolithic build: TODO
* [bjoern-michaelsen] the split requires a reoganization of the scp2 upstream component (for all supported platforms). Propose the split for deb/rpm, get buy-in for the other platforms : INPROGRESS
* [bjoern-michaelsen] cross build ARM (blocked/postponed due to java/qemu/threading madness -- bug 1129571): BLOCKED