On 13/08/2019 16:02, Cindy Sue Causey wrote: > 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 Cindy
:~$ apt-cache policy love love: Installed: 11.1-2 Candidate: 11.1-2 Version table: *** 11.1-2 500 500 http://mirror.bytemark.co.uk/debian buster/main amd64 Packages 100 /var/lib/dpkg/status Package described by apt search love is love/stable,now 11.1-2 amd64 [installed] 2D game development framework based on Lua and OpenGL Paul > 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 :) -- Paul Sutton http://www.zleap.net gnupg : 7D6D B682 F351 8D08 1893 1E16 F086 5537 D066 302D https://fediverse.party/ - zl...@social.isurf.ca
