[install UI must default to DTRT for naive users doing
 first-time installs]

[ heuristcs abut what goes where, and whether tha's local vs remote,
  are likely to lose -- need arbitrarily specifiable prefixes]

I think we're in violent agreement about both issues.

Personally, I differ about the UI, since I find it convenient to
install on diskless clients by booting diskless and populating the NFS
server.  (when client and server are different arches or even OSes.)


All i want is to forestall arguments that've already been thrashed out
in the (informal) postmortem of sysinst and its many failings, on
issues where a consensus was reached amongst the developers.  Ther're
lots of us, sometimes with very different preferences or local
configurations, and if we can all reach agreement on something, its
probably going to work OK.

>  In particular, rules about where packages
>are allowed to install files seem doomed to me, the only result from that
>can be that packages are split into two (or more), and someone has to make sure
>that all always get installed and deleted as a set (and remain consistent).

Sure. The prefixes dont entirely solve that either, though.  Sometimes
readonly exports from the server, combined with centralized (facist?)
managementare the only way to go.
[Eek, did I say that? Why does it remind me of AFS?]

Anyway, I still think the right approach is to nail down the pkg-set
format, do the conversion from tarball-sets to pkg-sets, and then play
with options. 

Hm.   while I remember:
    One thing that was suggested was a sh-like keyword=value syntax,
with defaults for first-time users in the pkg-set themselves; that
lets smart users "tape-record" a set of options, preferences,
whatever, and reuse them.  Plus its extensible: "older" versions of
sysinst can handle "newer" pkg-set options by just ignoring keywords
they dont grok.  I'd favour "stanzas" myself, but you get the point.