dpkg incorrectly installs singular-doc in jammy Docker container

[Dima Pasechnik]

Also reported on https://github.com/tianon/docker-brew-ubuntu-core/issues/230

Using official Jammy image in Docker (macOS) and Podman (Fedora).
In both cases, using CLI in the image and running

apt install singular-doc
dpkg -V singular-doc
reports a lot of missing files. In fact, the only present files are dangling links to missing files in the package.
(EDIT: the latter should not be there, it contradics `exclude` policy for dpkg installed in the Docker image)

The package itself is not broken - extracting it in Jammy not in Docker/Podman (say, in an lxc container) works.
And extracting it in Debian/bookworm CLI run in Docker works too.

As well, the same behaviour is observed using the corresponding singular-doc_4.2.1-p3+ds-1_all.deb file, and installing it using dpkg -i. This points to dpkg as the culprit.

[Dima Pasechnik (dimpase)]

What's unusual about singular-doc_4.2.1-p3+ds-1_all.deb ? I suppose

* data.tar is compressed using zst

* it contains symbolic links within the tarball.

The data.tar.zst tarball extracted from .deb works fine in Docker image CLI (assuming zstd is installed), so I presume it's something to do with dpkg expaning the file by itself.

This was found while working on https://trac.sagemath.org/ticket/32789

[Julian Andres Klode (juliank)]

This is a feature, not a bug.

Docker images are not intended for interactive use, as such use minimized images, and dpkg is configured to not install any documentation.

A script 'unminize' is provided to convert a minimized image into a full one.

root@3a7cdb2c772b:/# cat /etc/dpkg/dpkg.cfg.d/excludes
# Drop all man pages
path-exclude=/usr/share/man/*

# Drop all translations
path-exclude=/usr/share/locale/*/LC_MESSAGES/*.mo

# Drop all documentation ...
path-exclude=/usr/share/doc/*

# ... except copyright files ...
path-include=/usr/share/doc/*/copyright

# ... and Debian changelogs for native & non-native packages
path-include=/usr/share/doc/*/changelog.*

[Dima Pasechnik (dimpase)]

This was discovered during the run of a CI, and interactive steps are provided for the ease of reproduction, not because it's the way it was found. If you don't know how to use Docker images interactively, it doesn't mean they are not used this way.

Also, even if I'd agree that Docker containers are useless for interactive work (I don't) note that the steps still install broken symbolic links into /usr/share/doc.
One sees

# ls -l /usr/share/doc/singular/html/
total 0
lrwxrwxrwx 1 root root 13 Dec 17 20:20 sing_1068.png -> sing_1008.png
...
root@c9df22f5e5ab:/sage# ls -l /usr/share/doc/singular/html/ | wc -l
71

And I really think that it's up to the user to decide how to use Docker containers, and you should not break things like this. By the way, Jammy lxc container does not show this bug - are you telling me that lxc images are OK for interactive work, but Docker containers are not?

Containers/images are very useful for quick testing of whatever pops up, and breaking system packages like this is very bad.

I wasted a day chasing this weirdness up - dpkg should at the very least emit a warning that it drops things in such a case.

[Dima Pasechnik (dimpase)]

And if you want to keep this behaviour, at least make sure `dpkg -V` reports that files are missing due to a policy, not cause it's a bug.

[Julian Andres Klode (juliank)]

Yes, lxd containers are full-fledged system containers which also target interactive users. The focus of the docker community is vastly different, focusing on the smallest possible containers:

https://ubuntu.com/blog/minimal-ubuntu-released

It's odd you end up with anything inside /usr/share/doc, does dpkg still extract excluded symlinks? This needs further investigation.

Changing dpkg -V, I don't know, maybe, it seems to support an error message for "missing"

[Julian Andres Klode (juliank)]

I have verified that the symlinks somehow end up getting installed although they should have been excluded. This also happens upstream in Debian.

If we just have path-exclude=/usr/share/doc/*, it gets excluded. Once we add path-include=/usr/share/doc/*/copyright, the symlinks in /usr/share/doc/singular/html get installed.

[Julian Andres Klode (juliank)]

Note that it was not clear from the bug report that it was installing broken symlinks that it should not have. I assumed it was installing expected broken symlinks, like a /usr/share/singular/doc symlink to /usr/share/doc/singular, that's why I provided the information so you know what's going on, and closed the bug as that would have been expected.

[Dima Pasechnik (dimpase)]

Sure, when I was filing the report I had no idea what's really going on - the only indications were `dpkg -V` reporting missing files, and broken links in /usr/share/doc.

[Julian Andres Klode (juliank)]

So the reason why the symlinks are there is because they could be pointing to directories and then if you had a file extracted in there, you'd get not found if you'd skip the symlink. Like consider

/usr/share/doc/foo/bar as a symlink to /usr/share/foo/bar

and another package installs a file into /usr/share/doc/foo/bar/ rather than the canonical location.

This is documented in the dpkg manual page and tracked upstream in

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859646

dpkg -V is tracked upstream in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975338

[Dima Pasechnik (dimpase)]

In this case the links are not pointing to directories, they are pointing to files in the same directory. So there is no excuse to install them.

[Julian Andres Klode (juliank)]

Sorry but a symlink is just a symlink, it points to another name. It does not contain a flag saying whether it points to a file or a directory, so you can't know.

[Dima Pasechnik (dimpase)]

All these links points to names like foobar.png, but what's important that they point to locations excluded by the policy (actually, the same directory where the links reside!).

As long as the policy is in force, nothing can be installed to locations they point to - besides more broken links, of course.

I actually don't understand the rationale of all this - even if these links are pointing somewhere else, there should be nothing in that directory, by policy!