On 8/13/19, Nektarios Katakis <nektar...@mail.nektarioskatakis.xyz> wrote: > On Tue, 13 Aug 2019 11:33:17 +0100 > Paul Sutton <zl...@disroot.org> wrote: >> On 13/08/2019 11:16, Nektarios Katakis wrote: >> > From what I see the love2d software provides 2 packages for linux. >> > One specific to Ubuntu distro and one with AppImage. You re not >> > mentioning which one you used to be able to reproduce. >> >> I am installing with >> >> apt install love (as root of course) >> >> How do I perhaps query dpkg to see what exactly it has installed etc? >> > > > You can check that with `apt list --installed | grep <package-name>'. > Can you please show the output of `apt-cache policy love`? > love package is not in the mainline apt repositories (I cannot find it).
Hi.. I was able to find it in Buster while lurking along just now: pool/main/l/love/love_11.1-2_amd64.deb Dpkg suggested dpkg-deb. I played a few seconds with the resulting observations being.. * Sometimes you might need the whole page name including the version and dotDEB instead of only the name without those very specific identifiers. * Sometimes the package must at least be downloaded locally but not necessarily installed. "apt-file list" was able to show what "love" offers even though love is nowhere near my own setup. Apt-file worked great when called upon from any ol' directory, too. Apt-file did NOT like being offered a full path regardless of that path being any of these: /var/cache/apt/archives/rurple-ng /var/cache/apt/archives/rurple-ng* /var/cache/apt/archives/rurple-ng_0.5+16-2_all.deb A possible "why" is maybe the full path is internally addended to how "apt-file" is intelligent enough to already know that /var/cache path without us having to type it out in full. That would explain apt-file working with only a package name offered from anywhere within our file hierarchy. As such, apt-file might be reading those 3 full paths redundantly as: /var/cache/apt/archives/var/cache/apt/archives/rurple-ng* For dpkg-deb, these worked: dpkg-deb --contents /var/cache/apt/archives/rurple-ng* dpkg-deb --contents /var/cache/apt/archives/rurple-ng_0.5+16-2_all.deb Because the immediately above worked, this next one understandably did not and instead presented as "No such file or directory": dpkg-deb --contents /var/cache/apt/archives/rurple-ng The following only worked from within /var/cache/apt/archives AND also from within a duplicate, generic backup's directory: dpkg-deb --contents rurple-ng* In other words, dpkg-deb seems to poke around similar to how "ls" does. Those were *my* experiences, anyway. Totally worthwhile few minutes spent because the comparisons are a peek into package programming/development options/style variances, too. An observation overall is.. don't forget that any kind of change within dependencies could be the root of what's going on, too. The mere thought of that just made my head spin. PySolFC just experienced that a few weeks ago, broke completely, after one or more of its Python dependencies were upgraded. Cue the *crickets* stinger.. :) Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with 2 Python tutorials and more editors than she can remember inquisitively, experimentally installing k/t Debian CHOICE! *