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/44HCX5BVFZKYHUZB4QBFARIUV2TKZJXE/

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: