On Wednesday, 22 March 2017 4:41:32 AM AEDT Guillem Jover wrote: > > > # dpkg -S /usr/lib/systemd/libsystemd-shared-232.so > > > dpkg-query: no path found matching pattern > > > /usr/lib/systemd/libsystemd-shared-232.so # dpkg -S > > > /lib/systemd/libsystemd-shared-232.so > > > systemd: /lib/systemd/libsystemd-shared-232.so > > > # ls -l /lib > > > lrwxrwxrwx. 1 root root 7 Jan 5 15:04 /lib -> usr/lib > > > > > > I think that dpkg should know that those 2 filenames are the same and > > > return the package systemd in both cases. > > > > That's a long-standing problem, first reported 15 years ago. > > Not really, this case is the reverse, which is searching for the > canonical path on the filesystem, but which is not the canonical > one on the dpkg db. > > Solving this from the dpkg side, is non-trivial if not impractical. > It would require either scanning the whole filesystem to find aliased > pathnames. Or hardcoding the mappings, which would be encoding local > policy into dpkg somehow, which it might get out-of-sync with the > filesystem contents. Or possibly other ugly things.
/etc/selinux/default/contexts/files/file_contexts.subs_dist has the following contents in the next policy for Unstable: /bin /usr/bin /lib /usr/lib /lib32 /usr/lib /lib64 /usr/lib /libx32 /usr/lib /sbin /usr/sbin /etc/init.d /etc/rc.d/init.d /lib/systemd /usr/lib/systemd /run/lock /var/lock /usr/lib32 /usr/lib /usr/lib64 /usr/lib /usr/libx32 /usr/lib /usr/local/lib32 /usr/lib /usr/local/lib64 /usr/lib /usr/local/lib /usr/lib Why not have a directory for config files listing equivalent paths for the purpose of dpkg -S etc? Above is the equivalency file for SE Linux, this is needed because SE Linux uses the canonical path name for the initial labelling of security contexts. To do that we need to know all the path names. Now the above isn't going to suit dpkg -S exactly. With SE Linux labelling we consider lib, lib32, lib64, and libx32 to be equivalent as the same file name in multiple directories has the same security implications but obviously not the same dpkg use. If we had a directory for subs files for the purpose of dpkg then usrmerge and anything else with similar operations could install a file to make dpkg -S work. > I covered this in #848622. So, unfortunately, this part, I don't think > is fixable. And as I've stated before, while I think the idea behind > merged-/usr is fine, the way it's been deployed is not, but this was > ignored as a non-issue, so… > > I think this should be wontfixed, and closed. But if someone can come > up with a clean way to handle this, I'm open to suggestions. It should not be closed. Set it to wontfix for the moment if you must, but please leave it open so it's a known issue (otherwise it will keep getting reported) and so that anyone else who has any ideas can add them. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
