Hi! On Thu, 2015-12-17 at 10:18:35 +0100, Didier Roche wrote: > Package: dpkg > Version: 1.18.3
> In a project (Ubuntu Make), I have my small tests running as non root, > but this one needs to install packages. > What I did until now is to use (as apt is used to fetch packages from a > local repo) a "fakeroot dpkg --root" wrapper with a local crafted > directory to simulate, add packages and architectures to test that > everything is behaving as expected. You can see that testbed setup at > https://github.com/ubuntu/ubuntu-make/blob/master/tests/small/test_requirements_handler.py#L54 > for instance. > > The issue started recently with pkg-config shipping a post-invoke hook > in /etc/dpkg/dpkg.cfg.d/pkg-config-hook-config. > As this isn't running in a real chroot (I didn't want to deboostrap for > the small tests, just telling to apt and dpkg "please fetch from this > path and install there", the system config (good for testing) and hooks > are run. However, /usr/share/pkg-config-dpkghook isn't aware about > --root= option, and it's trying to do things system-wise like unlinking > some architectures pkg-config files (which fortunately fails as non root). This is something I've been aware for some time now, and it also started being a problem for dpkg functional test suite itself, and for the future no-chroot support in dpkg. > I wonder what's the correct way to handle this. I didn't find any way to > tell dpkg to not run the post-invoke hooks, only to add some to the > linked list of actions. I'm not even sure if this is the correct choice. > Also, as the hook is harcoding paths, I can't "hide" it as non root (as > a bindmount would enable me to). > > What do you think is the best direction for such case? dpkg growing an > option for this? Having the hook being aware it's not running in a real > environment? I'm thinking that dpkg should grow a new --confdir option (which I've almost got implemented locally), and --root should also modify that, so that the configuration is taken from the correct place. And the logging directed to the correct destination too. Thanks, Guillem