https://bugzilla.suse.com/show_bug.cgi?id=1219107 Bug ID: 1219107 Summary: Migrate away from update-alternatives (phase 1) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs@suse.de Reporter: martin.schreiner@suse.com QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- Following the mailing list thread: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/4... And the summarised view of the discussion, as presented on the Wiki: https://en.opensuse.org/openSUSE:Update-alternatives_migration We'd like to keep pushing for libalternatives to be adopted, replacing update-alternatives where feasible, leaving the door open for certain packages to use Conflicts and/or systemd units where applicable. This will have to be considered on a case-by-case basis, but for the majority of packages, libalternatives should work just fine, as it supports setting default binaries and manpages tied to a particular alternative choice. I therefore propose the following: Phase 1) We identify common packaging patterns regarding the update-alternatives -> libalternatives migration. For instance, some packages are fairly straightforward, and do not require regular files to be changed based on an alternative setting. They may not even provide different manpages. Some packages do provide different manpages based on a given alternative. And some packages provide different arbitrary files based on alternative. We'll document and provide examples on OBS/IBS as to how these should be handled. Phase 2) We communicate. Word needs to get out. Everyone doing packaging should be aware that update-alternatives is being slowly phased out. Labs Conference may be a good place to spread the word. We also need to let our users know what's going on. The Tumbleweed announcement blog, the mailing list, even Reddit, all of these could play a role. We'll explain our rationale and try to prevent any backlash from the community. If anyone provides valuable feedback, we'll approach carefully, openly, always keeping the project's best interest at heart. Phase 3) We make ourselves available. Should anyone need help, or any particularly tricky migration require our help, we can be counted on. When I say "we", I mean any developer who's interested in this migration and is willing to help our efforts. Of course the Pack team plays a special role, but anyone interested is more than welcome to be a part of this. This is a sizable change. We need to stick together. -- You are receiving this mail because: You are on the CC list for the bug.