docs/guide/slots-and-use.btft

[table class="topnav"]
[tr]
[td class="logotab"]mp[e]
[td][see name="index"]index[e][e]
[td][see name="guide/index"]guide[e][e]
[td][see name="reference/index"]reference[e][e]
[e]
[e]
 
[h1]slot and use, together[e]
 
SLOT and USE flags are separate mechanisms, but the interesting behavior -- and the behavior that confuses people first encountering it -- happens where they meet. this page is written from a user's seat: what you'll actually see happen, and how to control it. reference/slots.html covers the resolution mechanics for the same material.
 
[h2]why do I have curl AND curl:ssl installed?[e]
 
a port whose pkg_slot_use lists "ssl" gets a DIFFERENT effective slot depending on whether USE=ssl is on for it at install time. install curl once with USE=ssl off, then again with it on (globally, or via a per-package "curl: USE=ssl" section), and you get two coexisting installs: curl (unslotted, ssl off contributed nothing to the slot) and curl:ssl, each with its own prefix. neither install touches the other. this is deliberate, not a bug -- it's what lets a dependent package pin exactly the variant it needs (see below) without forcing every other consumer of curl onto the same USE setting.
 
[h2]how do I pick which one gets used?[e]
 
for a bare, unqualified reference (pkg_deps="curl", or "mp install curl" with no slot), mp picks among whatever's installed by pkg_pref, lowest wins -- same tie-break as any %tag provider choice. to pin a specific slot instead, name it explicitly: "mp install curl:ssl", or in a port's own pkg_deps="curl:ssl". a dependency that names a slot explicitly also gets that exact build's prefix wired into its own CFLAGS/LDFLAGS/PKG_CONFIG_PATH automatically -- it will link against curl:ssl specifically, never whichever curl happens to sit on the default search path.
 
[h2]"mp slots" -- seeing what's actually there[e]
 
[code]
mp slots gcc
[e]
 
lists every port directory declaring pkg_name=gcc: each one's effective slot, its pkg_pref, whether it's installed, and which one a bare "mp install gcc" would auto-pick (lowest pkg_pref among installed candidates -- this command never disagrees with what a real install would actually resolve to).
 
[h2]removing a slot something else depends on[e]
 
blocked by default, with a clear reason:
 
[code]
err: curl:ssl cannot be removed: still linked against by: somepkg (--force to override)
[e]
 
"mp revdep curl:ssl" shows the same list without attempting a remove, if you want to check before deciding whether to also update/remove whatever depends on it.
 
[h2]setting USE for a slot that doesn't exist yet[e]
 
USE= is always set under a port's BARE name (curl: USE=ssl), never under the slot it will eventually produce -- the composed slot doesn't exist as a config section until mp has actually resolved it once. this is the same reason HOLD/MASK/hook_<phase>=/DEPS overrides all fall back to the bare name too: write your override under the bare name, and it applies regardless of which slot(s) that name ends up producing.
 
[h2]a static slot and a use-driven one, together[e]
 
pkg_slot and pkg_slot_use compose: a port declaring both pkg_slot="12" and pkg_slot_use="lto" produces gcc:12 (lto off) or gcc:12-lto (lto on) -- version and feature-state vary independently, and both coexist if installed. reference to either is exactly what you'd expect: gcc:12-lto, no different from any other slot string.