Christopher M. Punches
c41adc2498
dpm_require no longer takes a minimum version and applies no version criterion of its own. A handle now means the module is valid, not that it suits the caller. dpm_module_info_of is added alongside it, reporting the name, version, description, and minimum-libdpm-core version read at load, so a consuming module can judge a dependency's version for itself. The one rule still enforced is the minimum-version handshake, where libdpm-core is the host and refuses a module that demands a newer library than the one running. dpm_module_info_of joins the version script, so the exported surface is now fourteen symbols under DPM_CORE_1.0. Separately, the bare word "core" is gone from prose everywhere. It named both the command-line tool and the library, so every use forced the reader to guess which. Text now says "the dpm binary" or "libdpm-core". Identifiers keep their spelling: libdpm-core, core.h, core.conf, the "core" configuration namespace, dpm_core_version, core_min, DPM_CORE_1.0, the dpmcore namespace, test_core, core_api. Three user-visible strings changed with it: the load-refusal message now reads "requires libdpm-core >= X, running libdpm-core is Y — update libdpm-core", and the info module's description and help text name the library. The test asserting on the refusal text was updated to match. DESIGN.md's terminology line no longer defines "DPM Core" as the CLI, which was the source of the ambiguity. OVERVIEW.md is restructured around the three layers a reader meets DPM at — user, developer, filesystem — so a code-level symbol never appears without saying whose layer it is. MODULES.md describes the bundled info module as testing and demonstrating full DPM system functionality rather than as a reference implementation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
