Bug#1035820: 9base: leaves entries in /etc/shells after upgrade from bullseye

[Helmut Grohne <helmut@subdivi.de>]

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.

> The following (untested) snippet for the postinst should perform the
> neccessary cleanup:
> 
> if [ "$1" = "install" ] || [ "$1" = "upgrade" ]; then
>     if dpkg --compare-versions "$2" lt-nl "1:6-14~" ; then
>         remove-shell /bin/rc
>         remove-shell /usr/lib/plan9/bin/rc
>     fi
> fi

No. Please continue to use the declarative approach.

Helmut