Control: severity -1 normal On Tue, Nov 07, 2023 at 10:40:46PM +0100, Andrea Pappacoda wrote: > I do agree with this reasoning. As mentioned in one of the old threads about > this, in my opinion it would've been better to have a general, more > restricted "sysusers" alternative command which could've been provided by > opensysusers and systemd-sysusers, and would be used by things like > dh_installsysusers and the like. Stepping into the "systemd-" namespace > without actually supporting all the features *and* closely following new > feature additions is asking for trouble. And, since the upstream developers > (i.e. the Artix Linux maintainers) stopped development in favour of > systemd-standalone-sysusers[1], I'm now more inclined to change approach and > drop diversions.
The second of my patches implements this. > > A possible compromise could be that opensysusers stops diverting > > systemd-sysusers and installs the symbolic link without diversion such > > that systemd becomes the preferred provider when coinstalled. It could > > detect removal of systemd using file triggers and then reinstate the > > link. Such a setup also requires little cooperation from systemd > > maintainers, but it relies on an symbolic link that is completely > > untracked by dpkg, so there is some fragility to be found here whereas > > the conflict is conceptually simpler. > > I'm not sure I follow, but choosing an approach which isn't tracked by dpkg > doesn't sound right to me. There is prior art for this approach. For instance, some packages required compatibility symlinks for tools moved from /bin to /usr/bin. Such symlinks could not added to data.tar as they would break on merged-/usr instances. Therefore these were managed as untracked files using maintainer scripts. This is not nice, but technically feasible. It was not my preferred option and hence there is no patch for this. In any case the goal of that approach would be providing the systemd-sysusers command from a systemd or systemd-standalone-sysusers happens to be installed and providing it from opensysuser whenever neither of them is installed. > I want to fix this too, and I really thank you for the help. I'm inclined to > drop the diversions, but I'd first like to fully understand the consequences > (e.g. would something break for someone?). What do you need to know to gain this understanding? I suppose you want to talk to Thomas here. I respectfully disagree with Thomas, so I am probably not well suited to represent his view. Given that systemd conflicts with opensysusers in experimental, we could also just close this bug. The /usr-merge related bug arises from the coinstallability that has now been revoked. You only need to do something if you want coinstallability back or clean up (now) unused diversions. Helmut
