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

Reply via email to