The command line I am using is
dpkg --force-not-root --root /some/other/location -i the_package.deb
but I get an error
dpkg: could not open log '/var/log/dpkg.log': Permission denied
I would have expected the log to have been written to
/some/other/location/var/log/dpkg.log
With rpm you can generate an alternate database but I can't see how to do this with dpkg. To get to the above state I manually added (perhaps not the wisest approach) the following.
mkdir -p /some/other/location/var/lib/dpkg/updates
mkdir -p /some/other/location/var/lib/dpkg/triggers
mkdir -p /some/other/location/var/lib/dpkg/info
touch /some/other/location/var/lib/dpkg/status
touch /some/other/location/var/lib/dpkg/available
If I try to run as root, which I would prefer not to do in this case
sudo dpkg --force-not-root --root /some/other/location -i the_package.deb
it gets further and installs the deb in my alternate location but then fails with
dpkg (subprocess): unable to execute installed post-installation script (/var/lib/dpkg/info/the_package.postinst): No such file or directory
but this file has been written by the dpkg command above to
/some/other/location/var/lib/dpkg/info/the_package.postinst
My reasoning for not using the machines dpkg database is that this is an applications software install to a network drive that is available to a number of users. Perhaps just extracting the contents of the package and manually installing is the best approach. The particular software package does not have any external dependencies listed.
Debian 'dpkg' package management program version 1.18.2 (amd64)
Best Answer
Use
--log=filename
to change where you log.If you are using
--root=/foo
you need to set up/foo
as a valid root. E.g.,sudo chroot /foo /bin/sh
works.The "No such file or directory" is indicating that the
the_package.postinst
script requires something that is not in the chroot (most likely/bin/sh
and a boatload of other things). That is run from within the chroot so you don't see/foo
in the path.You could use
--no-triggers
to prevent the triggers from running. However you should now see what a hack this is becoming.dpkg
is heavily biased toward thinking you want to run the package on the machine on which you are installing it and the root filesystem is at/
."[J]ust extracting the contents of the package and manually installing it will be a better approach." Yes-- it looks like you are installing it on a file server that is not intended to run it.
Edit: Though this strictly solves your problem the "modern" method to distribute software is to use orchestration software (e.g., chef) to install the packages directly on the clients rather than sharing software via a fileserver. Disks are cheap.