Package: docker.io Version: 28.5.2+dfsg4-2 Severity: normal Hello Reinhard,
the issue is easy to reproduce: start a Debian:sid container or VM, and install docker.io. Output: ``` [...] Preconfiguring packages ... Configuring docker.io --------------------- The /var/lib/docker directory contains Docker images, containers, and volumes. If you choose this option, all this data will be permanently removed when the docker.io package is purged. If you are replacing docker.io with another Docker distribution (like docker-ce), or if you want to keep your data, you should choose not to remove it. Remove all Docker data? [yes/no] yes Selecting previously unselected package libcom-err2:amd64. (Reading database ... 4918 files and directories currently installed.) [...] ``` Since I'm installing the package on a clean system, there is no data, so why does it ask me to remove data that doesn't exist? I suppose the code could be gated to the upgrade case only (ie. if [ -z "$2" ] in the postint). This bug report is about installing docker.io in a clean environment, but we can extend it to upgrading systems where docker.io is already installed. The postinst basically asks me, when the package is upgraded: > Remove all Docker data? [yes/no]" However it doesn't remove any data, it just sets a flag to remove or not remove data _later_ when (if ever) the package is purged. I think the wording is confusing. Another thing that is confusing, from this message: > If you are replacing docker.io with another Docker distribution (like > docker-ce), or if you want to keep your data, you should choose not to > remove it. I am not replacing anything, I am just upgrading my system. But wait. So I'm supposed to decide _now_ what to do with the data? How can I take a decision for an event that didn't happen yet? Maybe next year, I will remove the package, or maybe I will switch from docker.io to docker-ce. So it's the answer that I gave 1 year ago that will decide what will happen to my data? I think this approach is not going to work. I've had a brief read at #1021914, and I read it as a bug report from a user that configured APT to always purge data, and was then surprised to see that APT purged its data... I think this APT config flag is dangerous, and users shouldn't set it on their system. Maybe the APT documentation should be more explicit that setting this flag is not a great idea. If ever docker's data is so important that it warrants an exception, and should leave data behind even when it's purged, then maybe ask the question about what to do _at the moment_, ie. when the package is purged? However packaging best practice say that "prompting in any case can only be in the configure stage of the postinst script", cf. <https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#best-practices-for-maintainer-scripts> I don't have the right answer here, I'm not really familiar with debconf. I'd be tempted to drop all the debconf thing here. Either purge data, or don't purge data, no need for more granularity. What does podman do in this case? What about incus? Maybe just align with those packages. Hope that helps. Best, Arnaud
