On Sun, 17 Mar 2024 at 11:23:28 +0900, Simon Richter wrote: > When /bin is a symlink to usr/bin, > and I install two packages, where one installs /bin/foo and the other > installs /usr/bin/foo
My reading of Policy is that this situation is already a Policy violation: To support merged-/usr systems, packages must not install files in both /path and /usr/path. For example, a package must not install both /bin/example and /usr/bin/example. —§10.1 and in the case of /{usr/,}{s,}bin in particular (which is the most likely place for this to happen), doubly so: Two different packages must not install programs with different functionality but with the same filenames —also §10.1 (I'm interpreting that as "install programs into the PATH" which I hope is the intended reading.) So I think the precise way in which the system goes wrong in this situation is unimportant, because the situation already shouldn't exist? Until we reach the point where every package's data.tar contains only non-aliased paths (files below /usr, /etc and /var, plus additional top-level paths in base-files), it seems to me like the best way to handle this would be a QA tool that detects any such situations that might exist in the archive, and makes sure they have appropriate Conflicts to stop the bad scenario from occuring in practice. But, after we reach the point where every data.tar contains only non-aliased paths, by definition this situation cannot arise, because there will be no remaining packages with files /bin/foo, /sbin/foo or /lib*/foo. It seems like we are quite close to that point (mainly thanks to Helmut's efforts in that direction) after which this will be a non-issue, so maybe providing such a QA tool would be a wasted effort. smcv