3

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)

user993269
  • 43
  • 1
  • 5

1 Answers1

3

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.

Mark Wagner
  • 17,764
  • 2
  • 30
  • 47
  • 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 01 '16 at 15:08
  • Thanks, that helped, but I must say that mentioning "chroot directory" is confusing. That is because you can't `chroot` as a non-root, but then the question is about doing `dpkg` installation as a non-root… I get you meant that the destination dir of the dpkg command should be a system that one could chroot into if they wanted so, but it's not obvious one the first read. I think it might help to be explicit with something like "The dpkg destination dir should be a system that one could chroot into if they wanted". – Hi-Angel Mar 30 '21 at 14:56