Hi Matthew (2025.02.25_16:59:44_-0400) > I call for votes on the below ballot. The vote is open for 7 days, or > until the outcome is beyond doubt. > > In Bug #1091995, the Technical Committe was asked to rule on an issue > that could, under certain circumstances, result in failure of the > base-files package to install or upgrade correctly. Under these > circumstances, systemd will create a symlink from /lib64 to /usr/lib, > which does not match the symlink contained within base-files. base-files > will detect this case in preinst and generate an error, but if it did > not do this then dpkg would instead fail with a less verbose message. > > Policy does not currently define ownership of the usrmerge filesystem > aliases, but since trixie base-files has effectively been responsible > for ensuring that these aliases are configured appropriately. This is > therefore a technical disagreement rather than a policy violation. > > A) The Technical Committee affirms that base-files should own all > top-level filesystem aliases, and packages that conflict with this must > be patched in Debian to avoid creating any aliases that conflict with > base-files (overrules the systemd maintainer, requires 3:1 majority > vote) > > B) The Technical Committee requests that base-files create an empty > /usr/lib64 directory, even on architectures that do not use lib64. If > systemd creates a symlink, this will then match the behaviour of > base-files and avoid the issue (overrules the base-files maintainer, > requires 3:1 majority vote) > > C) The Technical Committee requests that base-files preinst check > whether /lib64 is a symlink to /usr/lib and, if so, replace it with a > symlink to /usr/lib64 (overrules the base-files maintainer, requires 3:1 > majority vote) > > N) None of the above / Further Discussion
I vote: A > N > B = C Rationale: This really seems like a systemd bug in violation of the way we usr-merge. I could see it making sense on distributions without multiarch, but not Debian. We could obviously live with this and work-around it in other packages, if necessary. But I haven't seen any compelling reason for needing to do that. Ideally this would be resolved upstream in systemd, as this affects Debian containers in systemd-nspawn on other distributions. I vote B and C equally, as I believe the base-files maintainers can select between these options (that they disagree with) themselves. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
signature.asc
Description: PGP signature
