Re: DPM § 7.2 and proposal for Pre-Recommends
Hi,
On Sat, Sep 07, 2019 at 07:07:37PM -0700, Kip Warner wrote:
> Consider the scenario where there may be a package A that recommends a
> package B (say, a local database instance instead of a remote one).
Service dependencies like this are not usually tracked in the package
system, because we don't have an appropriate relationship. The closest
thing I could come up with is
Recommends: B | A-remote-B
where "A-remote-B" is either an empty dummy package or contains the logic
to connect to a remote service. That should be enough to get a local
service by default, and allows for easy overrides by asking apt to install
"A" and "A-remote-B" in the same invocation.
> Perhaps A is a system service that does not require B. But if B is
> configured A may need to do something during its postinst hook as a
> convenience to leverage B immediately.
That just sounds like a nightmare for centrally coordinated installations.
Service dependencies like these need to be "managed" by demand-activation
at runtime, because we do not have a service orchestrator that accurately
maps these relationships, because such a tool would be overkill for Desktop
installations, and at the same time not powerful enough for datacenter
deployments.
If we cannot express these relationships in the service orchestrator, then
we certainly cannot express them in the package manager, which has even
fewer assumptions about the system to work with.
A postinst script to apply debconf configuration values cannot verify the
correctness of information, because it might be running in a limited
environment (e.g. a policy-rc.d setting that inhibits service startup,
because we're currently preparing a container image and do not actually
intend to run the service).
All we can do at this point is write a service configuration that we think
is going to work when the first request comes in.
If you want to react to the B package being installed later, use a dpkg
trigger to reconfigure your package, but be aware that B might still not be
running at this point -- all that dpkg can give you is an ordering of
postinst invocations, but that is less than you need for the scenario you
describe.
Simon
Reply to: