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.

Transcript

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
7. 8 Happy User
8. 9 Discovering New Software
9. 10 Discovering New Software
10. 11 Searching
11. 12 Searching
12. 13 Installing
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 Distribution
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/