# pkg

Experiments in package management for 9front.

Some basic ideas:

 * use C for both package manager tool and package descriptions, don't @ me
 * use unionfs to avoid polluting `/`: http://a-b.xyz/83/1c9b
 * (heavy?) use of namespaces to achieve per-user installations
 * subcommand to go through all packages to figure out which ones might need an update
 * automate maintaining as much as possible
 * `$pkgname.$arch.tgz` as a binary package, with meta packed inside
 * allow installing into the root system bypassing any special namespacing
 * "try out"

kvik's brain dump:

```
here's some thoughts i have on the matter.  for now i'll mostly ignore
the details of how exactly packages get described, updated, and built,
even though this is a harder and very important part of the deal.
however, i think that nailing down the end product usage should help
guide us in the right direction.  so:

a) a result of a package 'build' is a $pkgname.tgz distribution unit, a 'package'.
b) a package is made up of a rooted 'footprint' of its contents, ie what commonly
   would be resulting artifacts of mk install. possibly a meta file describing the
   package could be produced and included. some trivial example footprint would be:

	/bin/git/*
	/home/lib/git		# ideally we force a nice 'lib' *mountpoint*,
                  # as with /bin, but i digress.

c) package installation is private by default (though system-wide option shouldn't
   make much difference). it consists of:

 -1) building the package,
 1) loading the package to a cache,
 2) unpacking the footprint into a per-package faux 'root',
 3) finally, the 'actual' installation, call it 'activation'.

up to 3) is quite straightforward.  for the 'activation' there is a
lot of different choices that i'm not comfortable making for different
users.  with the footprint unpacked a user is free to 'activate' in
any way they please, partly or fully; however, wherever, whenever they
want.  still, we could provide some usable defaults that make using
pkg enjoyable:

 1) forcing normal installation under some chosen prefix, probaly not
    bothering too much about unassisted uninstall for this case,
 2) 'tryout' bind into the current namespace, should leave the disk
    entirely unaffected even after most experimentations with the pkg,
 3) 'persisted' activation via maintaining some 'binds' file sourced by
    user's profile or some unionfs trickery, either static or dynamic.
 4) whatever else might be useful.

i propose 'pkg' to live in a $pkg directory under some prefix,
probably $home/pkg.  everything related to packages, from development,
build, up to usage, is contained underneath here.  some spitball
structure:

	src/
		# the source of package manager itself, including
		# package database and whatever.
	build/ # package build staging roots, or w/e
		...
		$pkgname/
			...
	package/ # binary package cache
		...
		$pkgstring.tgz
	root/ # extracted footprints
		...
		$pkgstring/
			bin/
				binary
			lib/
				data0
				dataZ
	pkg/
		# possibly some configurations,
		# persistent state, etc.

the result is that a user wanting to, say, try out git9, could run:
	pkg try git9

we'd then check for package updates, fetch them, build the software,
package it up, extract the footprint, and finally temporarily activate
it with something equivalent to:
	unionfs -m/ / $home/pkg/root/git9-$revision/

making fresh git9 available in /bin/git as expected.  this activation
can then be variously persisted, as hinted before.
```