This bug affects the latest unmasked version (1.15.2) and the latest ~amd64 masked one (1.15.8.4) too. When I try to install a .deb package, I get the following error: aatiis@aiur ~/tmp $ sudo dpkg -i google-talkplugin_current_amd64.deb dpkg: failed to open package info file `/var/lib/lib/dpkg/status' for reading: No such file or directory aatiis@aiur ~/tmp $ l /var/lib/lib/dpkg total 16K drwxr-xr-x 2 root root 4.0K Aug 20 03:52 alternatives drwxr-xr-x 2 root root 4.0K Aug 20 03:52 info -rw-r----- 1 root root 0 Aug 20 03:58 lock drwxr-xr-x 2 root root 4.0K Aug 20 03:52 parts drwxr-xr-x 2 root root 4.0K Aug 20 03:52 updates aatiis@aiur ~/tmp $ eix dpkg [D] app-arch/dpkg Available versions: 1.15.2 (~)1.15.3 (~)1.15.3.1 (~)1.15.4 (~)1.15.4.1 (~)1.15.5.2 (~)1.15.5.2-r1 (~)1.15.5.3 (~)1.15.5.4 (~)1.15.5.5 (~)1.15.5.6 {bzip2 linguas_de linguas_es linguas_fr linguas_hu linguas_ja linguas_pl linguas_pt_BR linguas_ru linguas_sv nls test unicode zlib} Installed versions: 1.15.8.4(03:52:45 08/20/10)(bzip2 nls unicode zlib -dselect -linguas_de -linguas_es -linguas_fr -linguas_hu -linguas_ja -linguas_pl -linguas_ru -linguas_sv -test) Homepage: http://packages.qa.debian.org/dpkg Description: Package maintenance system for Debian aatiis@aiur ~/tmp $ dpkg --version Debian `dpkg' package management program version 1.15.8.4 (amd64). This is free software; see the GNU General Public License version 2 or later for copying conditions. There is NO warranty.
We don't support installing .deb archives using dpkg directly. Please write or request an ebuild.
Ok, sorry for spamming. But what is "dpkg" used for then? I didn't create an ebuild as googletalk plugin is binary-only with lots of crazy dependencies.
http://tinderbox.dev.gentoo.org/misc/rindex/app-arch/dpkg has a list of packages that use it. For your purpose, please CC yourself on bug #333539, which is a request for an ebuild for the google talk plugin.
You probably mean bug #333579.
Er, right. :)
not supporting direct install of .debs are fine, but going his error output, i think something is broken in our setup/install of dkg. it should be accessing /var/lib/lib/...
(In reply to comment #6) > not supporting direct install of .debs are fine, but going his error output, i > think something is broken in our setup/install of dkg. it should be accessing > /var/lib/lib/... JFYI, if I "touch /var/lib/lib/dpkg/{status,last}" and symlink my "rc-update" to "update-rc.d", it works...
(In reply to comment #0) > This bug affects the latest unmasked version (1.15.2) and the latest ~amd64 > masked one (1.15.8.4) too. 1.15.2 isn't in the tree anymore. Stable 1.15.6.1 doesn't appear to be affected. I find this in 1.15.8.4: ./configure.ac:admindir="${localstatedir}/lib/${PACKAGE_NAME}" And ./configure --help says: --localstatedir=DIR modifiable single-machine data [PREFIX/var] So obviously Gentoo is doing it wrong.
commit 9bc511c4a0ed86e63963616dc1f224e6d8fcb615 Author: Guillem Jover <guillem@debian.org> Date: Mon Jun 7 01:12:26 2010 +0200 build: Change default admindir to LOCALSTATEDIR/lib/dpkg The old LOCALSTATEDIR/dpkg admindir default forced to set localstatedir to /var/lib, which is not correct. We can now set it to the correct /var. configure.ac | 4 ++-- debian/changelog | 2 ++ debian/rules | 2 +- 3 files changed, 5 insertions(+), 3 deletions(-) Which was first released in 1.15.8. We could easily override econf and set --localstatedir=/var in the ebuilds as a workaround.
This bug persists, in both 1.15.8.10 and 1.16.0.3 (the latest amd64 and ~amd64 packages, respectively). If dpkg isn't supposed to be used for installing .deb packages, what is?
(In reply to comment #10) > This bug persists, in both 1.15.8.10 and 1.16.0.3 (the latest amd64 and ~amd64 > packages, respectively). If dpkg isn't supposed to be used for installing .deb > packages, what is? It isn't supposed to be used for installing .deb packages on Gentoo systems at all. For one thing, we Gentoo developers wouldn't support that at all, but try to encourage you to write ebuilds that convert .deb packages into things Gentoo package managers can properly install. However, it should help you use *debootstrap and other utils to install .deb packages into chroots.