0

I have installed a particular program via apt. It originates from a 3rd party repo, and I have 100% confidence the file was installed & updated via apt not some other path (per data I list below)

I have stripped the specific package name because I would like to know (A) do I understand dpkg --search capabilities correctly, and (B) faced with an unknown-to-dpkg file, how do I definitively figure out where it came from?

$ which -a foobaz
/usr/bin/foobaz
/bin/foobaz

These^ are distinct but identical:

  • files exist
  • neither are symlinks (test -L $file fails) OR hardlinkes (stat -c %h -- $file prints 1)
  • have the same ctime and mtime
    • note the package has been updated recently, all the times^ look correct to me.
  • have identical sha1sum hashes

but dpkg only seems to know about the first one?

$ dpkg --get-selections  | grep -i foobaz
foobaz              install

$ dpkg-query -S /usr/bin/foobaz 
foobaz: /usr/bin/foobaz
dpkg-query -S /bin/foobaz 
dpkg-query: no path found matching pattern /bin/foobaz

Shouldn't dpkg -S <file> always know about the files added by the debs/apt? How should I approach this issue to determine where some 'unknown' file originated when I know with high confidence it was installed with apt?

some bits flipped
  • 359
  • 1
  • 5
  • 15
  • 2
    "These^ are distinct but identical" likely /bin is symlinked to /usr/bin - see for example why there is two identical bash? – steeldriver Aug 21 '23 at 18:18
  • @steeldriver - no, they are not symlinks, as I specify in my question. test -L and ls -al ... unless I'm running those checks incorrectly. – some bits flipped Aug 21 '23 at 18:23
  • 3
    It is not the files that are symbolicly linked, it's the parent directories (look at the output of ls -ld /bin) – steeldriver Aug 21 '23 at 18:34
  • dpkg -S /path/to/foobaz will indeed know about any installed packages that provide that file. However, that number of packages is usually 1. More than one package that provides the same file must be accounted for in the control file, or apt will throw a terminating error: "Package X is attempting to overwrite File A, which is also provided by already-installed Package Y." Debian worked all this out over 20 years ago. – user535733 Aug 21 '23 at 18:35
  • Oh, OK @steeldriver, that would make sense. It would seem this is a red-herring then (I was stumped by this while poking around trying to understand https://askubuntu.com/questions/1483131/apt-cache-policy-lists-repos-not-shown-in-add-apt-repository-list?noredirect=1#comment2596954_1483131). If you add this as an answer I'll accept. If possible, please include any hints on how this would be easy to figure out in the general case - now that you point it out, /bin -> usr/bin/ is somewhat obvious, but is there a way to ask in bash "do these files resolve to the same inode|blocks|etc? – some bits flipped Aug 22 '23 at 01:31
  • 1
    now seeing the root cause, I do agree that the root cause is shared with the "duplicates" linked - however, I'm this is not terribly helpful behavior to mark this as duplicate - the best way I can think to explain my viewpoint is an example: closing as Dup is the same as shutting down a student asking about some cellular traits they observe in lympphocytes, because the same phenomenon was explained elsewhere using erythrocytes as an example. Same root cause? Yes, absolutely. Same question? Not really, and certainly not from the perspective of the next person searching! – some bits flipped Aug 22 '23 at 01:44
  • 1
    @somebitsflipped that's the entire point of duplicates - people asking about the same thing in different ways. That's precisely how closing questions as duplicates helps in searching - people search for X or Y, doesn't matter, they reach the correct place. – muru Aug 22 '23 at 08:12
  • 2
    Does this answer your question? why there is two identical bash? – Artur Meinild Aug 22 '23 at 08:15
  • 2
    Does this answer your question? Why are /bin and /sbin now symlinks in Ubuntu 20.04? – BeastOfCaerbannog Aug 22 '23 at 09:13

1 Answers1

0

dpkg does not make any attempt to resolve links, bind-mounts, or any other such 'duplicate view' of files/inodes/directories, even within the same filesystem. It would be difficult (impossible?) to resolve all such cases especially in the general case (more than one filesystem, as many installs use). It also likely hues closer to the Unix philosophy of "do one thing well".

On some systems (including recent Ubuntu's), /bin is a symlink to /usr/bin, meaning logic that "searches" (such as which) will see two copies, but logic using static ~manifests (such as dpkg) will see just the file(s) explicitly install. Because this is a directory symlink, it's also transparent / not directly discoverable looking at the file entry itself on the underlying inode, one must examine all the parents.

some bits flipped
  • 359
  • 1
  • 5
  • 15