Split OpenOffice.org build Petr Mladek Build Engineer [email_address]
Content <ul><li>Changes for developers and release engineers
Solution in openSUSE-11.1/SLED11
Work in progress
Long term plans
Links </li></ul>
Changes for Developers and Release Engineers
Advantages for Developers <ul><li>Faster build </li><ul><li>Build only what is being developed
Writer hacker need to build just sw
Fix annoying bug in one hour
Does not help with low-level stuff </li></ul><li>Better defined structure </li><ul><li>Similar functionality in similar pi...
Easier to understand what each module is for
Search 30 instead of 200 modules
Force reasonable dependencies </li></ul></ul>
Disadvantages for Developers <ul><li>where is the module? </li><ul><li>modules with unclear content and group
motivation to create reasonable architecture </li></ul><li>global changes </li><ul><li>split source tree
external people have problem to upstream global changes even now; need discussion with more Sun teams
split officecfg, scp2; might be easier in the end </li></ul></ul>
Changes for Release Engineers <ul><li>advantages </li><ul><li>small security and maintenance updates
build only what is needed
Upcoming SlideShare
Loading in …5
×

Future of Installation Packaging

447 views

Published on

Future of Installation and packaging of OpenOffice.org

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Future of Installation Packaging

  1. 1. Split OpenOffice.org build Petr Mladek Build Engineer [email_address]
  2. 2. Content <ul><li>Changes for developers and release engineers
  3. 3. Solution in openSUSE-11.1/SLED11
  4. 4. Work in progress
  5. 5. Long term plans
  6. 6. Links </li></ul>
  7. 7. Changes for Developers and Release Engineers
  8. 8. Advantages for Developers <ul><li>Faster build </li><ul><li>Build only what is being developed
  9. 9. Writer hacker need to build just sw
  10. 10. Fix annoying bug in one hour
  11. 11. Does not help with low-level stuff </li></ul><li>Better defined structure </li><ul><li>Similar functionality in similar piece
  12. 12. Easier to understand what each module is for
  13. 13. Search 30 instead of 200 modules
  14. 14. Force reasonable dependencies </li></ul></ul>
  15. 15. Disadvantages for Developers <ul><li>where is the module? </li><ul><li>modules with unclear content and group
  16. 16. motivation to create reasonable architecture </li></ul><li>global changes </li><ul><li>split source tree
  17. 17. external people have problem to upstream global changes even now; need discussion with more Sun teams
  18. 18. split officecfg, scp2; might be easier in the end </li></ul></ul>
  19. 19. Changes for Release Engineers <ul><li>advantages </li><ul><li>small security and maintenance updates
  20. 20. build only what is needed
  21. 21. optimized build dependencies: </li><ul><li>parallel build of pieces
  22. 22. full distribution rebuild </li></ul><li>easier to produce noarch RPM packages </li></ul><li>disadvantages: </li><ul><li>more packages more work </li><ul><li>More spec files and changelogs
  23. 23. Helper scripts might help a lot </li></ul></ul></ul>
  24. 24. Solution in openSUSE-11.x/SLED11
  25. 25. Principles <ul><li>10-20 pieces are ideal
  26. 26. group by functionality
  27. 27. group by dependencies (no cycles between groups)
  28. 28. limited time frame before SLED11
  29. 29. Better something than the current state </li></ul>
  30. 30. 19 pieces <ul><li>bootstrap
  31. 31. ure, sdk
  32. 32. libs-extern, libs-gui, libs-core, components
  33. 33. filters
  34. 34. base, calc, impress, writer
  35. 35. extras, l10n, help
  36. 36. postprocess
  37. 37. extensions
  38. 38. testing </li></ul>
  39. 39. Techical solution <ul><li>two solvers </li><ul><li>system(devel packages), piece
  40. 40. $PATH, LD_LIBRARY_PATH, -L
  41. 41. some hardcoded paths to the right solver </li></ul><li>lazy tools </li><ul><li>apply.pl, build.pl, make_installer.pl </li></ul></ul>
  42. 42. Experience <ul><li>working application
  43. 43. successful minimal maintenance updates
  44. 44. easier to verify build fix
  45. 45. needed helper scripts for building, updating spec files and changelogs
  46. 46. GNOME and KDE dependencies are not clean
  47. 47. hacky -prebuilt packages
  48. 48. still need improvements to be usable by developers and to be acceptable upstream
  49. 49. Linux only </li></ul>
  50. 50. Work in progress
  51. 51. Give it to developers <ul><li>configure/make/make install for each piece
  52. 52. share setting via pkgconfig files
  53. 53. avoid hardcoded paths to the right solver
  54. 54. configure/make/make install -world
  55. 55. make from-piece
  56. 56. make A+B
  57. 57. keep compatibility with Windows </li></ul>
  58. 58. Long term plans
  59. 59. Beautiful world <ul><li>remove: </li><ul><li>officecfg, setup_native, scp2 – split per piece
  60. 60. postprocess – register components another way </li></ul><li>separate build </li><ul><li>icon themes – remove cyclic dependency
  61. 61. l10n after postprocess (against devel packages)
  62. 62. helpcontent (just the global setting)
  63. 63. GNOME, KDE – clean up build and package dependencies </li></ul><li>split/clean up: </li><ul><li>svx
  64. 64. More I/O filters </li></ul></ul>
  65. 65. Noble dream <ul><li>LSB-compliant installation </li><ul><li>configuration in /etc
  66. 66. noarch stuff in /usr/share
  67. 67. can't make it relocatable easily </li></ul></ul>
  68. 68. Related Links
  69. 69. Related links <ul><li>packages for older openSUSE distros </li><ul><li>http://download.opensuse.org/repositories/OpenOffice.org:/STABLE/
  70. 70. http://download.opensuse.org/repositories/OpenOffice.org:/UNSTABLE/ </li></ul><li>ooo-build and split upstream sources </li><ul><li>http://cgit.freedesktop.org/ooo-build/ </li></ul><li>more information about ooo-build </li><ul><li>http://go-oo.org/ </li></ul><li>approach by Mathias Bauer </li><ul><li>http://wiki.services.openoffice.org/wiki/Build_environment_Dependencies
  71. 71. http://blogs.sun.com/GullFOSS/entry/a_split_build_for_openoffice </li></ul></ul>
  72. 72. Questions?

×