Installing on UniData

Installing MVPKG on Rocket UniData

MVPKG is the bootstrap client: you install it once, by hand, and from then on it installs and manages everything else (MVPKG install mvx-lang/git, …). On UniData the client is a handful of cataloged BASIC programs plus a one-time host setup (the shared CallC aggregator). These steps were validated on UniData 8.3.2.

Prerequisites

Rocket UniData with $UDTHOME set, and the C toolchain + code generators that ship with it (gcc, gencdef / genefs / genfunc on PATH) — needed by packages that contribute native CallC code (e.g. git).
curl on the host — the client shells out to it for HTTP.
Rights to write $UDTHOME (setup installs a host script and, on install, rebuilds the shared CallC library) — sudo or root.

1. Get the client source

Download the published source release (or clone mvx-lang/mv_package):

curl -sL https://github.com/mvx-lang/mv_package/releases/download/1.0.2/mvx-lang_mvpkg-1.0.2-source.tar.gz | tar xz
cd mvx-lang_mvpkg-1.0.2-source    # or the extracted directory

The UniData client lives under udt/.

2. Create an operator account

Make a directory a UniData account — this is where you'll run MVPKG:

mkdir ~/mvpkg && cd ~/mvpkg
$UDTHOME/bin/newacct
#   Do you want to continue (y/n)?      y
#   Please enter account owner's login name:   <your login>
#   Please enter the account group name:       <your group>

newacct provisions VOC, BP, and the other system files.

3. Host setup (once per UniData host)

setup.sh installs the CallC aggregator (udt-callc-build) into $UDTHOME/bin and globally catalogs the capability probe CALLC.EXISTS (so any account can ask whether an optional native add-on is present):

sudo env UDTHOME=$UDTHOME sh /path/to/udt/setup.sh ~/mvpkg

4. Compile and catalog the client

The client is built on the cmd command framework: MVPKG is a thin dispatcher (CMD.INIT/CMD.ADD/CMD.RUN) that hands each subcommand to its own handler subroutine (MVPKG.INSTALL, MVPKG.INFO, …), backed by shared helpers (MVPKG.REG/.META/.ONE) and the OS seam. A cut-down copy of cmd ships in udt/CMD.BP so the bootstrap needs nothing else.

From the operator account, copy the client programs into BP and build them:

cd ~/mvpkg
cp /path/to/udt/MVPKG* /path/to/udt/MVPKGOS /path/to/udt/MVPKGDEP \
   /path/to/udt/SEMVER \
   /path/to/udt/HTTPGET /path/to/udt/HTTPGETFILE \
   /path/to/udt/JSONDECODE /path/to/udt/MAPFIELD \
   /path/to/udt/CMD.BP/CMD.INIT /path/to/udt/CMD.BP/CMD.ADD \
   /path/to/udt/CMD.BP/CMD.RUN  BP/

# every program except the MVPKG verb is cataloged globally (handlers are
# reached by `CALL @name`, so they must resolve); MVPKG is a LOCAL verb.
GLOBAL="MVPKGOS MVPKGDEP HTTPGET HTTPGETFILE JSONDECODE MAPFIELD SEMVER
        CMD.INIT CMD.ADD CMD.RUN
        MVPKG.REG MVPKG.META MVPKG.ONE
        MVPKG.INSTALL MVPKG.INFO MVPKG.LIST MVPKG.UPDATE MVPKG.REMOVE
        MVPKG.REGISTER MVPKG.SEARCH MVPKG.SETUP MVPKG.CONFIG MVPKG.REBUILD MVPKG.INIT"
{
  echo "BASIC BP $GLOBAL MVPKG"
  for p in $GLOBAL; do echo "CATALOG BP $p FORCE"; done
  echo "CATALOG BP MVPKG LOCAL FORCE"
  echo "QUIT"
} | udt

The seam functions, the cmd framework, and every subcommand handler are cataloged globally (so MVPKG's CALL @handler dispatch resolves and any account can CALL the helpers); MVPKG itself is a LOCAL verb so you can type it in this account.

Then provision the account (records the registry, ensures the store + manifest):

:MVPKG init
mvpkg initialised
  registry: https://mv-package.heydon.io
  store:    /path/to/$UDTHOME/mvpkg
install packages with:  MVPKG install <name>

5. Verify

:MVPKG config
registry: https://mv-package.heydon.io

:MVPKG info mvx-lang/git
name:         mvx-lang/git
version:      1.2.2
description:  git for hash-file records (branch/merge)
dependencies: mvx-lang/cmd

Install a package

:MVPKG install mvx-lang/git

This resolves and installs the dependency (mvx-lang/cmd) first, then for git: downloads the UniData binary, builds the CallC library from its udt-callc/ contribution (into $UDTHOME/bin/libu2callc.so), globally catalogs the in-session GIT verb, and deploys it into the current account. Then:

:GIT INIT
initialised empty git repository

Because installing writes to $UDTHOME (the CallC library, the global catalog), run MVPKG install with the privilege to do so.

Registering a standalone install

If you installed a package by hand — for example the standalone udt-git binary — before MVPKG was present, tell MVPKG about it so it manages the package and does not reinstall it as another package's dependency:

:MVPKG register mvx-lang/git
registered mvx-lang/git 1.2.2 (managed by MVPKG)

register only records the package (in the global store manifest and this account's manifest); it downloads and builds nothing. A later MVPKG install mvx-lang/git of the same version is then a no-op — a newer version still upgrades it.

MVPKG list shows everything MVPKG manages on this system:

:MVPKG list
installed packages:
  mvx-lang/git 1.2.2
  mvx-lang/cmd 1.0.7

MVPKG update [<name>] upgrades an installed package — or, with no name, every installed package — to the registry's current version:

:MVPKG update mvx-lang/cmd
updating mvx-lang/cmd 1.0.6 -> 1.0.7
installed mvx-lang/cmd 1.0.7 (globally cataloged)

MVPKG remove <name> uninstalls a package — the inverse of install: it un-deploys the package's verbs from this account, decatalogs its programs globally, unstages any CallC contribution (rebuilding libu2callc.so), drops the store copy, and clears it from the manifests:

:MVPKG remove mvx-lang/git
removing mvx-lang/git ...
removed mvx-lang/git

Options

Registry URL — override with the MVPKG_REGISTRY environment variable, or write the URL to ~/mvpkg.conf. It must be https — MVPKG installs code that gets compiled, cataloged and run, so it refuses a plain-http registry (a MITM code-injection risk). A localhost/127.0.0.1 registry is allowed for development; on a trusted private network you can opt out with MVPKG_INSECURE=1.
Package store — downloads land once per system in $MVPKG_STORE (default $UDTHOME/mvpkg); a re-install into another account only links it up.
libgit2 — the git package's CallC library links libgit2 1.9.x; ensure it is present at runtime (e.g. /usr/local/lib64).

Navigation Menu