XPost: linux.debian.bugs.dist
From:
guillem@debian.org
Hi!
On Mon, 2024-05-13 at 22:36:12 +0200, Johannes Schauer Marin Rodrigues wrote:
Package: dpkg
Version: 1.21.22
Severity: wishlist
Tags: patch
dpkg postinst fails to create the start-stop-daemon compatibility
symlink if /usr does not exist:
ln: failed to create symbolic link '/sbin/start-stop-daemon': No such file or directory
Getting into this situation requires some creativity. Here is an example:
$ mmdebstrap --variant=custom --include=dpkg,dash,diffutils,coreutils,libc-bin,sed unstable /dev/null
Here are two patches that fix this problem by just not creating the compatibility symlink in this situation:
Yes, thanks, as we discussed on IRC I think this is better than the
initially proposed change to create the directory, which would break
on usr-merged systems that ship /sbin as a symlink in base-files.
--- a/debian/dpkg.postinst
+++ b/debian/dpkg.postinst
@@ -59,7 +59,8 @@ setup_aliases()
# Add a backward compatibility symlink alias for s-s-d, which is now
# installed in its canonical location.
- if [ ! -f "$DPKG_ROOT/sbin/$prog" ]; then
+ # Skip creation of the compat symlink if /sbin is not an existing directory
+ if [ ! -f "$DPKG_ROOT/sbin/$prog" ] && [ -d "$DPKG_ROOT/sbin" ]; then
ln -s "/usr/sbin/$prog" "$DPKG_ROOT/sbin/$prog"
fi
}
--- a/debian/dpkg.postinst
+++ b/debian/dpkg.postinst
@@ -59,8 +59,10 @@ setup_aliases()
# Add a backward compatibility symlink alias for s-s-d, which is now
# installed in its canonical location.
+ # Failure to create the compat symlink (for example if /usr does not
+ # exist) is non-fatal.
if [ ! -f "$DPKG_ROOT/sbin/$prog" ]; then
- ln -s "/usr/sbin/$prog" "$DPKG_ROOT/sbin/$prog"
+ ln -s "/usr/sbin/$prog" "$DPKG_ROOT/sbin/$prog" || true
fi
}
The second patch has the advantage, that the user will receive the error message from ln about its inability to create the symlink together with the reason for the failure.
When I proposed suppressing the creation of the symlink I had in mind
and had locally the first approach, because it's less noisy, and I
assume users on those kind of systems will have logic somewhere to
handle that case anyway.
But I've been thinking that this still seems wrong from a conceptual
PoV, in that I think base-files should be unpacked as one of, if not
the first package as part of the bootstrapping protocol, as it encodes
the structure and metadata for the base filesystem. I think next would
be base-passwd as that also defines the metadata for the filesystem.
For example the symlink to dir and dir to symlink avoidance behavior
in dpkg would be one reason for this, another is that directory
metadata does not get updated if the directory exists, so the first
unpack wins.
I realize that we have continuously talked about wanting to avoid
encoding this kind of ordering in external tools, and this information
should be part of the packages themselves (which I still think is the
right approach). But I think we still could extend the packaging
and/or possibly the bootstrap protocol to cover this case.
One option would be to add dependencies within the bootstrap set on
both of these packages, but that goes counter to the no-depends on
essential packages, and would not be safe against other external
packages that might conflict with metadata definitions in base-files,
but it would work for the specific dpkg issue, and perhaps that would
be the better immediate fix. Another could be to mark these two base-*
packages somehow so that the bootstrap tools know in a generic way
that they need to unpack them first. I guess a field could be used,
something like the following comes to mind:
base-files
Bootstrap: fsys-tree
base-passwd
Bootstrap: fsys-meta
(or Bootstrap-Phase or Bootstrap-Order, or …).
Where I think the order should be:
fsys-tree → fsys-meta → rest of essential + dependencies
This does not solve the other bootstrap problem we've had in the past
with base-files requiring passwd information from base-passwd before
that has been unpacked, but I guess that might partially go away once
we can declare optional paths and template-based initialization
through fsys metadata so that the base-files maintscript can disappear completely. Although an external dpkg will still have a similar problem
as base-files currently does, and will need to either assume some name
to id mappings or use the ones from outside the chroot, but meh.
(But perhaps the solution to that last bit is for base-files to declare
the user/groups it requires as dpkg sysusers out of previously agreed definitions from base-passwd, then that would make it all self-contained.)
I'm working around this issue in the mmdebstrap test suite by creating /sbin manually in a hook. I'm filing this bug to not loose track of the situation and to be able to add a bugnumber to the hook.
Thanks. I'm happy to apply the ln suppression fix, or an explicit
dependency on base-files as an immediate solution to this for now.
But I think we should still explore better ways to handle this kind of situation.
Thanks,
Guillem
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)