Page 1 of 1
On dpkg -i a package, the dependency other than found dependencies are in a dir
Posted: Tue Jul 06, 2021 10:18 am
by almahdi
How do we tell on dpkg -i a package to get the dependency other than found dependencies, in a certain location ? e.g:
Code: Select all
$ sudo dpkg -i foobar_99_amd64.deb
(Reading database ... 355213 files and directories currently installed.)
Preparing to unpack foobar_99_amd64.deb ...
Unpacking foobar_99 ...
dpkg: dependency problems prevent configuration of foobar:
foobar depends on python3 (>= 3.9~); however:
Version of python3 on system is 3.7.3-1.
foobar depends on libc6 (>= 2.29); however:
Version of libc6:amd64 on system is 2.28-10.
foobar depends on libocct-foundation-7.5 (>= 7.5.1+dfsg1); however:
Package libocct-foundation-7.5 is not installed.
These three has been prepared in a dir., e.g., /baz
So how definitively solving it for foobar or another else package whenever some its depedencies are not ready on mainstream dir. but really are in the prepared one ?
Re: On dpkg -i a package, the dependency other than found dependencies are in a dir
Posted: Tue Jul 06, 2021 10:25 am
by dolphin_oracle
install the depends first. dpkg will not satisfy dependencies anyway. it merely checks for them.
Re: On dpkg -i a package, the dependency other than found dependencies are in a dir
Posted: Tue Jul 06, 2021 10:36 am
by timkb4cq
You can't tell apt/dpkg that python 3.9 is installed while python3.7.3 is still installed. That would violate the design of the apt/dpkg system.
That's a large part of the reason why flatpaks, snaps & appimages were created. They carry around their own dependencies, and thus are much larger & don't always play well with system themes.
Re: On dpkg -i a package, the dependency other than found dependencies are in a dir
Posted: Tue Jul 06, 2021 10:37 am
by almahdi
said above see
Code: Select all
foobar depends on python3 (>= 3.9~); however:
Version of python3 on system is 3.7.3-1.
can't be solved on stable
Re: On dpkg -i a package, the dependency other than found dependencies are in a dir
Posted: Wed Jul 07, 2021 12:13 am
by Stevo
ZOMG why are you even using dpkg for a deb install when we ship several different point-and-click tools for installing with the much superior apt or gdebi?
Use "sudo apt -f install" to remove that partially installed incompatible deb and hopefully sin no more. It'll never install on MX 19--maybe on MX 21 if that's not an Ubuntu deb.
Re: On dpkg -i a package, the dependency other than found dependencies are in a dir
Posted: Wed Jul 07, 2021 12:17 am
by Stevo
WT heck is foobar on linux and where did you get the deb? Foobar2000 is a popular Windows-only program that only runs here under Wine, but you may as well run Deadbeef from our repos instead.
Re: On dpkg -i a package, the dependency other than found dependencies are in a dir
Posted: Wed Jul 07, 2021 2:34 am
by andrewjoseph
OP may have meant "foobar" just as an example placeholder (almost like "John Doe" or "Jane Doe")
https://en.wikipedia.org/wiki/Foobar
Re: On dpkg -i a package, the dependency other than found dependencies are in a dir
Posted: Fri Jul 09, 2021 10:26 am
by timkb4cq
OP wants to install a deb package that requires python 3.9. He installed python 3.9 from source on his system his system which still has python 3.7.3 installed. He may be able to build his desired program from source, or install it using pip (if it's a python program in the pip system) or by manually extracting the deb and copying the files to their locations - but apt/dpkg can't install his deb unless he borks his whole system by installing python 3.9 with apt/dpkg.
OP doesn't want to accept that.
Re: On dpkg -i a package, the dependency other than found dependencies are in a dir
Posted: Sat Jul 10, 2021 12:06 am
by Stevo
Yes, but the dpkg output that they pasted in seems to argue against that--unless they strangely edited it and substituted foobar_99 for the real package name and version.
It shouldn't be a pure Python package if it says "amd64" and has a dependency on a newer libc6--we've ignored that huge obstacle up to now, but it's even worse on MX 19 than the Python 3.9 one, unless they can duplicate the "local libc6 directory" trick that we used to have to use for the Ubuntu Steam packages.