If you don't want to move from absolute paths for non-core packages, the current system should just work, right?
Yes.
The current system being the $topdir one.
Though it also allows for the possibility of relocatable sets of packages that are not installed relative to the compiler. But more importantly it's more general and simpler than the current '$topdir' that ghc uses.
'it' now being the new system evolving in this thread, or have I missed anything?
(a) making ghc-pkg (optionally) instantiate any variables in its database in (all of) its command-line output and
Yes, though I'm only asking for two vars (previously one), not an ad-hoc set of vars.
(b) allowing non-core packages to be relocated without having to update ghc-pkg's database.
In my suggested system this is possible if that set of packages use their own package db (containing relative paths).
That is news to me - was that specified before this thread moved to ghc-users?
In your system it's possible by updating some var in a central registry and having that set of packages use paths relative to that var.
So, essentially, your system would have to keep a file listing the various package.conf locations (currently, GHC only knows about two: system/user, everything else would have to be passed on the commandline..). While my system would have to keep a file listing the variable bindings, so that tools processing the package db can instantiate the variables. I could see both approaches being useful, even together.
So ghc's current system uses two vars, $topdir and $httptopdir.
This is GHC's view of its database. It should be useable independently, via ghc-pkg and ghc api clients (such as GHC, GHCi, Haddock, ..) - all of which should be able to resolve the variable bindings, in the same way. Btw, it would really be nice if the package handling code was shared rather than duplicated.
I'm proposing to replace those with a standardised ${pkgroot} and ${pkgrooturl} vars which are usable by all compilers and in more situations.
Now you are talking about Cabal's view of its database. It doesn't have to expose the underlying implementation's view, especially since the other implementations organise their package handling differently. And why just two variables? Is $pkgroot about .hi files, .a/.so./.dll files, or about include files, or haddock indices, or ..? In windows, these tend to end in a common sub-hierarchy, but you're aiming for something general, right?
You're proposing a central registry of vars and to have ghc-pkg (optionally) expand these vars which could be used anywhere in the installed package descriptions. Presumably you're also suggesting some mechanism to query and update this registry of variables.
Is that a fair summary?
I think so. And you're proposing several separate registries (hasn't that been a Cabal problem in the past, even with just user and system to choose from?). Presumably you're also suggesting some mechanism to query and update the meta-registry of package database locations. Claus