docs/guide/faq.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]faq[e]
 
[h2]does mp install prebuilt binaries?[e]
 
no. every port builds from source, every time (fetch/patch/build/install, or a legacy add.sh). there is no binary package format, no cache of prebuilt artifacts to trust or distrust.
 
[h2]why perl and c89 instead of one language?[e]
 
see reference/architecture.html for the full reasoning -- briefly, the two halves have genuinely different requirements. dependency resolution, config layering, and SLOT/USE composition need real judgment and change often; perl is easy to read and easy to change. filesystem operations (copying trees, snapshotting a prefix, parsing mpx.conf) need to be fast and hard to get subtly wrong; a small, strictly-warned C program is better suited to that than a scripting language would be.
 
[h2]why c89 specifically, and no GNU extensions?[e]
 
portability without asterisks. every function is fully prototyped, comments are always /* */ (c89 has no // at all), and the one place that genuinely needed a Linux-only, glibc-gated feature (unshare()/mount() for the sandbox, normally exposed behind _GNU_SOURCE) declares its own prototypes and uses the Linux kernel's own stable uapi constants directly instead -- see reference/architecture.html's sandbox.c section. the result builds under gcc, clang, or anything else claiming c89 conformance, on glibc, musl, or otherwise, with no feature-test-macro games.
 
[h2]what's the difference between pkg_deps, pkg_bdepend, and pkg_rdepend?[e]
 
pkg_deps is legacy shorthand for "needed both to build and at runtime" -- the common case, and what most ports should just use. pkg_bdepend/pkg_rdepend exist for the minority of ports that genuinely need the split (a codegen tool that's gone by runtime, say): pkg_bdepend is build-only, pkg_rdepend is needed at runtime too. "mp prune" only ever considers dropping a bdepend-only package nothing else needs at runtime.
 
[h2]how is this different from a binary distro's package manager?[e]
 
no prebuilt packages (see above), and a much smaller surface: no dependency solver juggling version ranges across an entire distro's worth of packages at once, no package database format shared with anything else on the system. a port is one file (pkg.conf) plus optional patches/hooks, readable top to bottom in a minute. the tradeoff is exactly what you'd expect: everything builds from source, so installing something for the first time costs real build time mp does not try to hide or shortcut.
 
[h2]how is this different from a from-source distro I've used before?[e]
 
the closest comparisons are things like Gentoo/portage or Exherbo/paludis (which these docs' own layout is modeled on) -- SLOT, USE flags, %tag-based virtual/provider resolution, and hooks will all feel familiar if you've used either. the concrete differences: pkg.conf's phase bodies are the shell script (no separate ebuild/exheres templating language to learn), SLOT composition can be driven directly by USE flag state (pkg_slot_use) with automatic buildlink-style dependency wiring rather than needing that wired by hand, and the whole tool is small enough to read end to end (see reference/architecture.html).
 
[h2]can I use multiple ports trees at once?[e]
 
yes -- see reference/multi-repo.html. REPO_<name>=/REPO_<name>_BRANCH=/REPO_<name>_PRIORITY= configure any number of independently git-backed repos, searched in priority order; CUSTOM_PORTS_DIR is a local override that always wins over all of them. the common single-repo case is unaffected and needs no configuration at all.
 
[h2]can I cross-compile with mp?[e]
 
yes -- see reference/config.html's sysroots section and [see name="reference/mpx-conf-example"]mpx.conf.example[e]'s TARGET_*/ARCH/MICROARCH keys. a sysroot is a wholly separate, independently tracked install root; TARGET_SYSROOT points a build at one for its headers/libs.
 
[h2]does mp sandbox builds for security?[e]
 
on Linux, each build/check/install/remove phase (never fetch, which needs real network) runs in a fresh network + mount namespace: no network but loopback, and the whole filesystem read-only except the stage dir and install prefix. this is explicitly defense in depth, not a hard security boundary -- a setup failure warns and falls back to running unsandboxed rather than blocking the build. see guide/troubleshooting.html if you're seeing those warnings and want to understand why.
 
[h2]where do I report a bug, or ask something this page doesn't answer?[e]
 
see this project's git hosting for issues/contact -- the same git.druid.rocks repo this documentation itself lives in.