Bugzilla – Bug 1219107
Migrate away from update-alternatives (phase 1)
Last modified: 2024-01-26 15:08:29 UTC
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.
I wrote a short Python script to analyse all spec files in openSUSE:Factory. It produces a report which contains the following information: The spec file name. The amount of alternatives is provides. A calculated MD5 hash for the set of alternatives, so that we can establish two spec files provide the same set of alternatives, by comparing its hash. The list of alternatives provided by said spec file. Note: The script isn't perfect, as finding the provided alternatives using regular expressions isn't a trivial problem. But it provides some basic guidance. The report is attached to this bug.
Created attachment 872111 [details] First report
Created attachment 872112 [details] Python script, V1
Of all the packages we have to migrate, I thought we could start with an easy one. "transmission" is a single spec file which creates a few different packages, a few of them providing the "transmission" alternative. As such, I decided to migrate this package myself, to serve as a starting point and to illustrate how future packages may be migrated. A working build is available here: https://build.opensuse.org/package/show/home:mschreiner:alternatives/transmission I've tested it and it works well, of course we'll have many more checks once it's submitted to Factory.