Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Distribute or Die - Arguing against Additional Repositories.

Distribute or Die - Arguing against Additional Repositories.

openSUSE has a wonderful platform with OBS, and tools like software.opensuse.org and 1-Click installs make it very easy for users to get additional software on their machines.

This talk will discuss how this is quite often a very bad thing, leading to problems for users as well as extra work for maintainers in both the short and long term.
It will discuss the benefits of putting software packages in both of openSUSE's distributions (Leap & Tumbleweed) and propose concrete steps which users and responsible package maintainers can take to ensure everything is put together and working as smoothly as possible.

Finally, the session will accept the reality that putting absolutely everything in a distribution is infeasible and discuss possible criteria and guidelines for sensibly defined, maintainable additional repositories that avoid the issues raised earlier in the session.


Richard Brown

June 25, 2016


  1. Distribute or Die Arguing against Additional Repositories Richard Brown –

    openSUSE Chairman rbrown@opensuse.org
  2. 3 A Game of Two Halves

  3. 4 A Game of Two Halves

  4. 5 There Will Be Blood

  5. Using our Software

  6. 7

  7. 8 Happy User

  8. 9 Discovering New Software

  9. 10 Discovering New Software

  10. 11 Searching

  11. 12 Searching

  12. 13 Installing

  13. 14

  14. 15 Package Not Available

  15. 16 Now what??

  16. 17 Searching for a Solution - SLE

  17. 18 Searching for a Solution - SLE

  18. 19 Searching for a Solution - SLE

  19. 20 Searching for a Solution - SLE

  20. 21 Searching for a Solution - SLE

  21. 22 Searching for a Solution - SLE

  22. 23 Searching for a Solution - SLE

  23. 24 Searching for a Solution - SLE

  24. 25 Searching for a Solution - SLE

  25. 26 Searching for a Solution

  26. 27 Searching for a Solution

  27. 28 Searching for a Solution

  28. 29 Searching for a Solution

  29. 30 Searching for a Solution

  30. 31 Searching for a Solution

  31. 32 1-Click Install – Click #1

  32. 33 1-Click Install – Click #2

  33. 34 1-Click Install – Click #3

  34. 35 1-Click Install – Click #4

  35. 36 1-Click Install – Click #5

  36. 37 1-Click Install – Click #6

  37. 38 1-Click Install – Click #7

  38. 39 1-Click Install – Click #8

  39. 40 1-Click Install – Click #9

  40. 41 1-Click Installs are BROKEN

  41. 42 Searching for a Solution

  42. 43 Searching for a Solution

  43. 44 Searching for a Solution

  44. 45 Searching for a Solution

  45. 46 Shell to the Rescue?

  46. 47 Happy Now?

  47. 48 Oh God No...

  48. 49 Oh God No...

  49. 50 Oh God No...

  50. 51 Oh God No...

  51. 52 Oh God No...

  52. 53 Oh God No...

  53. 54 Oh God No...

  54. 55 Scratching the Surface • Build Failures • Dependency Conflicts

    ‒ Pkg A from Repo $FOO conflicts with Pkg B from Repo $BAR • Unresolvable Dependencies • Broken Packages ‒ They are in a Devel Project for a reason ‒ Packages are MEANT to break in Devel projects
  55. 56 Devel repositories should not be used by users EVER

  56. How do we fix this?

  57. 58 Option A – Fix ALL THE THINGS • OBS

    ‒ Cross-Project Dependency Checker ‒ Freeze Project Publishing on Build Failure ‒ Create a new type of ‘stable:’ repo • zypper ‒ Hide ‘will NOT be installed’ warnings ‒ Redesign entire ‘vendor’ concept ‒ Add OBS & SLE Module Search functionality
  58. 59 Option A – Continued • YaST ‒ Add OBS

    & SLE Module Search functionality • 1-Click Install ‒ Fix EVERYTHING ‒ Stop it adding totally INSANE repos (Power_PC for x86_64?) ‒ Rename it 9+ Clicks • software.opensuse.org ‒ Simplify search ‒ Remove home: & devel: repos
  59. 60 Option A - Continued • Give up on RPMs

    entirely ‒ Sell soul to Mark Shuttleworth and build everything as Snaps ‒ Throw decades of good engineering practice out with Flatpaks ‒ Explain to our users how a ‘minimal’ installation is now over 40GB for 300 packages. ‒ Justify many GB of downloads when Java or openSSL needs a patch
  60. 61 Option B Add Your Bloody Packages To The Bloody

  61. 62 What should Users do?

  62. 63 What should Users do? Ask Maintainers To Add Their

    Bloody Packages To The Bloody Distribution
  63. Developing our Software

  64. 65 “Putting packages in to the distribution is too hard!”

    - Every single packager, ever, including me
  65. 66 Role of Devel Projects

  66. 67 Role of Devel Projects

  67. 68 Castles on Shifting Sand

  68. 69 You are perfect, but are they?

  69. 70 Don’t Misuse Devel Projects

  70. 71 Build only what you need • MANDATORY: Factory/Tumbleweed •

    OPTIONAL: Leap 42.x ‒ Where .x is the NEXT version of Leap • OPTIONAL: SLE_12_SPx ‒ Where x is the NEXT SLE Service Pack • Everything else is NOT suitable for a Devel Repo ‒ It’s more work for you to maintain it. Why waste time? ‒ It’s more work for OBS to build it. Why waste servers?
  71. 72 Do it right today, save work tomorrow • Tumbleweed

    today will become Leap 43.0 and SLE 13 tomorrow • Work at a relaxed pace today to avoid chaos in the future • Leap 42.x and SLE 12 SPx benefit from a healthy, feature filled Tumbleweed • Keeping packages outside of the Distributions hide MAJOR integration issues
  72. 73 You are not alone • opensuse-factory@opensuse.org • opensuse-packaging@opensuse.org •

    #opensuse-factory on irc.opensuse.org • Ludwig Nussel • Dominique Leuenberger • Max Lin
  73. 74 Let’s talk about Policies https://en.opensuse.org/openSUSE:Packaging_guidelines • Policies exist for

    good reasons ‒ Developed from solid engineering experience ‒ Developed from solid COMMUNITY experience • Shared with SUSE Linux Enterprise • No openSUSE policy is set in stone ‒ Discuss at opensuse-factory@opensuse.org
  74. Additional Repos Done Right

  75. 76 How SUSE Build Add-Ons SLE Package Hub Server Desktop

    Workstation Ext. SDK HA
  76. 77 Key Features • Most are “Cut from the same

    cloth” • Built Together, Designed to Work Together • Easy to Test Together • Each Extension/Module is no larger than it needs to be • Each Extension/Module moves only when it needs to
  77. 78 When openSUSE Should Build Add-Ons • “When there is

    no other choice” ‒ Do not add avoidable complexity for yourselves or users • Tumbleweed – No Add-Ons ‒ Always open for submissions, so no need for add-ons ‒ Exceptions – Prop. Kernel Modules, Packman • Leap – stable: “Backport” Add-Ons ‒ Users may want a ‘stable’ version of something newer than in the released Leap version
  78. 79 Idea – stable: Repos • Small, tightly defined repo

    ‒ “just enough to give the users what they need” • Built for openSUSE Leap ‒ OpenSUSE 13.1 & 13.2 end support in Nov 2016 / Feb 2017 ‒ SLE already has Package Hub https://en.opensuse.org/Portal:Backports
  79. 80 Concept – stable: repos devel: Python Tumbleweed Python Submit

    Backport stable: Python
  80. 81 Concept – stable: repos Leap stable: Python zypper addrepo

    zypper dup stable: Python Leap Python
  81. 82 stable: repo Theoretical Benefits • Frees devel: repos to

    be used for development • stable: repos able to move at the best pace for users • Makes it clear to users which add-ons are safe • Reduces complexity of current devel: mess • Small, targeted repos should be testable
  82. 83 stable: repo Problems • Narrow, targeted repos – How

    do we enforce this? • Dependencies between repos – How do we resolve? • Upgrade policy? • Maintenance Model? • Testing? Adding Packages To The Distribution Is EASIER
  83. 84 Recap • Maintainers, put your packages in the distribution!

    • Users, do not use packages from devel: projects! • stable: repos MAY be an option for specific stacks ‒ With significant effort by a lot of people • The status quo must not continue
  84. Thank you. Questions?

  85. General Disclaimer This document is not to be construed as

    a promise by any participating organisation to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. openSUSE makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for openSUSE products remains at the sole discretion of openSUSE. Further, openSUSE reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All openSUSE marks referenced in this presentation are trademarks or registered trademarks of SUSE LLC, in the United States and other countries. All third-party trademarks are the property of their respective owners. License This slide deck is licensed under the Creative Commons Attribution-ShareAlike 4.0 International license. It can be shared and adapted for any purpose (even commercially) as long as Attribution is given and any derivative work is distributed under the same license. Details can be found at https://creativecommons.org/licenses/by-sa/4.0/ Credits Template Richard Brown rbrown@opensuse.org Design & Inspiration openSUSE Design Team http://opensuse.github.io/branding- guidelines/