On 09/05/2023 16.55, Helmut Grohne wrote:
Control: forcemerge 1033167 -1
Control: affects 1033167 + 9base
Hi Andreas,
On Tue, May 09, 2023 at 04:39:21PM +0200, Andreas Beckmann wrote:
during a test with piuparts I noticed your package leaves modifications
in /etc/shells after upgrading from bullseye to bookworm and purging the
package.
9base/bullseye called add-shell/remove-shell in its postinst/postrm.
9base/bookworm no longer does that, but it also does not clean up the
leftover entries from bullseye in its postinst.
9base/bookworm no longer does, because it now uses dpkg-triggers to
perform the cleanup. It actually does clean up its entries.
>From the attached log (scroll to the bottom...):
0m45.2s ERROR: FAIL: After purging files have been modified:
/etc/shells not owned
You should look closer:
0m45.2s DEBUG: Modified(user, group, mode, size, target): /etc/shells
expected(root, root, - 100644, 128, None) != found(root, root, - 100644, 140,
None)
It's a 12 byte difference. That's not 9base's entries. What you see here
is "/usr/bin/sh\n". So this is a /usr-merge bug. We already know it.
Thus force-merging.
No, it's "/usr/bin/rc\n".
# cat /usr/share/debianutils/shells.d/plan9
/bin/rc
/usr/lib/plan9/bin/rc
If I install 9base in an unmerged-/usr sid chroot, I get
# /etc/shells: valid login shells
/bin/sh
/bin/bash
/bin/rbash
/bin/dash
/bin/rc
/usr/lib/plan9/bin/rc
/usr/lib/plan9/bin/rc
who is responsible for the duplicate entry?
If I install 9base in a merged-/usr sid chroot, I get
# /etc/shells: valid login shells
/bin/sh
/bin/bash
/usr/bin/bash
/bin/rbash
/usr/bin/rbash
/bin/dash
/usr/bin/dash
/usr/bin/sh
/bin/rc
/usr/lib/plan9/bin/rc
/usr/lib/plan9/bin/rc
same duplication ...
If I reconfigure usrmerge afterwards, I get
# /etc/shells: valid login shells
/bin/sh
/bin/bash
/usr/bin/bash
/bin/rbash
/usr/bin/rbash
/bin/dash
/usr/bin/dash
/usr/bin/sh
/bin/rc
/usr/lib/plan9/bin/rc
/usr/lib/plan9/bin/rc
/usr/bin/rc
Now we got the additional /usr/bin/rc entry
Andreas
