On Sat, Aug 21, 2021 at 10:30:21PM +0200, lorenzo wrote:
is this going to replace the old 'policy-rc.d' hack, or it's
a tool with different purpose?
No. policy-rc.d needs to work regardless. The purpose of DPKG_ROOT is
being able to use one Debian installation to operate (install/remove packages) on another.
Although I suspect that the common use case will be with systemd,
I want to add this to runit snippets and I wonder if this is a
replacement for the policy-rc.d hack or if I need to keep both..
The DPKG_ROOT feature is fully independent of the init system.
I admit not having thought about possible feature duplication with policy-rc.d. The line of reasoning was roughly this:
When DPKG_ROOT is non-empty, we know that there are (at least) two
Debian installations an "outer" one (whose dpkg binary we are using)
and an "inner" one that we operate on (and where DPKG_ROOT points to
from the outer one). Therefore, we know that no services are running
inside and can skip these things. Attempting to run them would
operate on the "outer" system anyway, so that's certainly not what we
In retrospect, this kinda is duplicating policy-rc.d and possibly, we
should remove the added DPKG_ROOT emptiness condition in favour of
using policy-rc.d. However, that is not trivial either. When running policy-rc.d, we will get the "outer" one, but we'd want the "inner"
one. So in order to make this work via policy-rc.d, we'd have to
prefix any policy-rc.d invocation with DPKG_ROOT.
Do you have any thoughts on this?
Can we move this to some public mailing list? I think email@example.com would do.
|Location:||Huddersfield, West Yorkshire, UK|
|Nodes:||8 (1 / 7)|