Hi, While I was checking the implications of the dpkg-shlibdeps breakage I realized that «dpkg-query --search» is also broken when deploying a merged-/usr with the method from this package. At least in two ways, when doing: $ dpkg-query -S /usr/<something> for a pathname that used to exist only in /<something>. And: $ dpkg-query -S /<something> for a pathname that used to exist only in /usr/<something>. The ways to trigger these will be different, one can happen when passing canonicalized pathnames to dpkg-query, the other might happend when a user on such merged-/usr system introduces the pathname that now resolves but is unknown to dpkg. From casual inspection it appears that packages calling dpkg or dpkg-query with -S or --search can potentially break stuff. Things like needrestart, checkrestart (from debian-goodies) as Linux's /proc/<PID>/exe points to the canonicalized pathname, reportbug is another obvious things that seems could break. But there are many to check. Anything matching the above on codesearch.d.n is a potential thing that will break and might need review and/or verification. Thanks, Guillem
Control: block -1 by 134758 Control: severity -1 normal Control: found -1 1 This is being addressed in #134758. would not work on non-merged systems. Over one year of experience with merged-/usr systems has not exposed any failures. Lacking concrete examples of regressions and considering the fact that this cannot be solved by the usrmerge package, I am lowering the severity of this bug.
With the release of debian 12 that includes the usrmerge, this now breaks a lot of docker containers (see https://github.com/docker-library/official-images/pull/14960) that have the following pattern: 1) save list of manual installed packages (saved=$(apt-mark showmanual)) 2) install dev packages 3) restore list of manual installed packages (apt mark auto '.*'; apt mark manual $saved) 4) compile && install stuff 5) use ldd + dpkg-query -S to find packages containing library dependencies 6) mark these packages as manual installed (apt-mark manual $dependencies) 7) purge all packages only needed for compile (apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false) Reading through the existing comments here, I understand the issues (performance, not wanting to hardcode path mapping etc) .. but I think I have come up with a possible solution that should (hopefully) satisfy all: I propose to introduce a third matching mode (besides the existing path and pattern matching modes): realpath. This mode can only be triggered by adding the "--realpath" argument. The pseudo code for this mode looks like this: 1) try to lookup by given path; if found => return results; 2) if not found; try to lookup by realpath(givenpath); if found => return results; 3) if not found; do pattern lookup with the following pattern: "*/" + filename(realpath(givenpath)) 4) filter the results to only include the paths where realpath(foundpath) == realpath(givenpath) 5) return results Alternatively we could skip step 1&2 and directly start with the pattern lookup; but that depends on the costs of those lookups and the benefits of those early exits. This way the performance of the existing modes is not affected and you minimize the performance impact of the realpath calls by limiting it to a pattern where the filename matches the filename of the realpath. If there is interest in this; I could allocate some time to have a look at the implementation of this.