1

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)

1

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.

  • Thanks. It looks like using dpkg is not the right approach for installing packaged software to a fileserver. Thanks for the tip about 'chef'. – user993269 Mar 1 '16 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.