Hi Thorsten,
On Thu, Aug 15, 2024 at 04:25:44PM +0000, Thorsten Glaser wrote:
> So, then. Give me a patch that:
I think what works best for mksh and pax is:
execute_before_dh_installdeb:
if command -v dh_movetousr >/dev/null; dh_movetousr; fi
In bookworm and earlier, this will notice that there is no dh_movetousr
and do nothing. In bookworm-backports, it will run dh_movetousr, but
dh_movetousr does nothing there. In trixie and later, it will move stuff
to /usr.
> • does not rely on the version of the packages (considering
> there are packages in external repos with higher version
> numbers that do not move)
I concur. Whether there should be a move is not a function of the
package version but a function of the target release. The proposed
change takes care of this.
> → even when later upgrading to such one (e.g. in case
> someone has trixie but also the external repo’s bookworm
> in sources.list, where the latter ships mksh with a
> higher version but without the move) ⚠
What you are requesting here is not well researched and I cannot easily
give any guarantees here. With all the aliasing going on, we have a hard
time reasoning about whether upgrades will work correctly and the main
goal of doing these moves is to get into a state where such reasoning
works again. Moving files back and forth should work in principle.
Otherwise, we wouldn't be doing it for large quantities of packages.
There are some limitations that you should be aware of:
* If you restructure or rename packages at any time where you still
have files aliased in some packages and moved in others, you're in
for trouble. Both mksh and pax have been single-binary-package source
packages for a significant time and it seems likely that you're not
going to change that any time soon. If you were to split out
mksh-static into a separate mksh-static binary package though, that
would cause file loss. Basically, any time you start using Replaces
with these packages, bad things happen.
* If someone attempts to divert (local or package) a file from mksh or
pax, they need to ensure that both the aliased and canonical location
are diverted or their diversion may become ineffective once upgrading
from aliased to moved or from moved to external (aliased again). The
most relevant diversion of /bin/sh (and later /usr/bin/sh) is not
relevant here as that file is not owned by mksh but owned by dash.
So the known cases of bad things happening do not look like they apply
to mksh nor pax and we have not seen evidence of other forms of breakage
when moving files back and forth, but there is little guarantee. Solid
reasoning arrives once all packages have moved their files and that's
the main reason for doing these moves.
> • ensures /bin/lksh is never nōn-existent on upgrades and
> downgrades
I think my earlier example of upgrading dash inside mmdebstrap
demonstrates that this is the case. dpkg renames stuff into place and it
has an inode-based check that prevents it from removing files it just
unpacked.
> Then I’ll grudgingly apply it.
Thank you
Helmut
