4.2 Satisfaction
A dependency is satisfied by a candidate when the conditions of PSPU
§5.21 hold: the name matches directly or through provides, any
constraint is met by the appropriate version, the architecture qualifier
is met, and the candidate is in the dependency's root.
Three consequences of those rules shape how peipkg behaves.
4.2.1 A goal may name a role #
An install goal is satisfied under the same conditions as a dependency,
with the goal's name in place of the dependency's. An operator may
therefore ask to install sh, cc, or coreutils and receive whatever
package provides it.
When a goal is satisfied by a candidate whose name differs from the one the operator typed, peipkg reports the substitution. This is a notice rather than an authorization: the operator is told, but an unattended run is not blocked.
A goal already satisfied by an installed provider is not recognised as satisfied: peipkg checks whether the goal's name is present, not whether something provides it. Asking to install a role that an installed package already provides therefore installs a second provider.
4.2.2 Upgrade and remove are name-only #
An install goal may resolve through provides. An upgrade, a downgrade,
and a removal do not: they act on a package already installed under a
specific name, and resolving them through provides would let an
upgrade substitute a different package for the one the operator named.
4.2.3 The architecture qualifier #
The only qualifier value is any, and anything else is rejected. any
means the candidate's architecture equals the depending package's
effective architecture, or is noarch.
For a noarch depender the effective architecture is the system's
primary architecture — a script's dependency on its interpreter resolves
against the concrete system being assembled. peipkg applies that rule
while selecting a candidate, not only when checking the finished plan.
Skipping the test during selection made any architecture satisfy a
noarch depender, a foreign one included. That candidate entered the
matching set, could win on version, was placed, and was caught only by
the consistency check — which rejects the whole resolution rather than
the one candidate. So a plan that a noarch candidate would have
satisfied failed outright.
Candidate selection for a dependency also filters by installability now, as selection for a goal and for a name already did.
4.2.4 Concrete dependencies are resolved before capabilities #
Package names and virtual capabilities use the same dependency syntax. Peipkg therefore treats a dependency as concrete when an available package has that exact name, and resolves those dependencies before capability-only entries.
This matters when packaging derives a shared-library dependency automatically. A package may explicitly depend on its intended library package and also carry a derived dependency on that library's SONAME. Resolving the SONAME first could select another provider; resolving the explicitly named package first installs the intended provider, after which its SONAME satisfies the derived dependency. The result does not depend on the order in which those two dependencies appear in the manifest.