Re: Love 2d and debian 10
On 8/13/19, Nektarios Katakis <nektarios@mail.nektarioskatakis.xyz> wrote:
> On Tue, 13 Aug 2019 11:33:17 +0100
> Paul Sutton <zleap@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! *
Reply to: