Hi Thorsten, On Wed, Aug 07, 2024 at 09:59:09AM +0000, Thorsten Glaser wrote: > >that the way people tend to use mksh is by adding a local diversion for > > Unfortunately not. > > The way we have to do it since squeeze, when dash unilaterally broke > cross-package coordination, is: > > dpkg-reconfigure dash ⇒ remove its owning of /bin/sh > (so it reverts to bash) > ln -sf lksh /bin/sh > > This cleanly persists across upgrades, bash was never problematic > wrt this.
I fear this approach no longer works. In bullseye and earlier, I guess it works. If you start with bullseye or earlier, upgrade to bookworm and then to trixie, it continues to work, because the dash maintainer scripts preserve any diversion that is not owned by dash. If you start with bookworm, the debconf stuff is gone and your dpkg-reconfigure does nothing. In order to change your default shell, you get to remove dash's diversion and do your own diversion. dash will not touch this diversion. Before you ugrade to trixie, you'll have to add a diversion for /usr/bin/sh. If you start with trixie, debconf and diversion management is gone. All that remains is code for removing the previous default diversion of dash. You get to do your own diversion and dash will not touch it. I see how the changes to /bin/sh management feel annoying to, but the target state bears quite some benefits in my view: * In forky, we will remove all maintainer script snippets related to management of /bin/sh (i.e. the remaining diversion cleanup). These maintainer scripts posed significant maintenance costs earlier. * It is rare to want to change /bin/sh and local diversions are a suitable and established mechanism to change package-installed files. * Managing debconf stuff from scripting can be more difficult than creating a local diversion. For the scripting use case it actually becomes easier. > There is absolutely no reason to force files to move, given they > are now aliased already *anyway*. The reason to force the file move is to entirely remove the problem categories listed at https://subdivi.de/~helmu/dep17.html. Removing entire classes of problems reduces the collaborative long-term maintenance cost of the distribution, but it incurs the one-time cost of performing the move. I see that you disagree with our judgement of the cost-benefit trade-off, but we have wide agreement inside Debian with this view. I've had long arguments about this a year ago listened to concerns and raised my own. I suggest that the time for arguing on this matter is over unless you bring new information to the table. Helmut
