I've started working on a package manager implementation, dubbed
"dorodango"[0]. I post this as a feedback request, not because there's
working code to show yet.

dorodango is/will (ATM) be based upon these concepts, which I hereby put
up for discussion:

- Bundles: A bundle is a ZIP file, containing the actual files (Scheme
  libraries, documentation, data, ...) as well as one or more
  "sys-def.scm" files containing metadata (see the next point).

  There may either be a single such file in the toplevel directory, or
  one or more in subdirectories (of depth 1). If a sys-def.scm file is
  found in the toplevel, all other potentially considered sys-def.scm
  files are ignored.

  A bundle may as well be represented by a directory on disk, which is
  treated the same way.

- Systems: A system is the "unit of software" dorodango works with. It
  has a name (a symbol, possibly along with a namespace tag), and a
  version, which may be used to form dependency relationships among
  packages.

  A system's files are grouped into categories (e.g. (R6RS) libraries,
  documentation). Each category contains a set of (relative)
  filenames. The actual filenames need not directly correspond to the
  filenames of the bundle they are contained in; A system definition may
  specify a mapping (see below).

- sys-def.scm files: They contain the name, version, dependencies, file
  mapping, etc. for one or more systems, each described by a
  `define-system' form, for example:

  % cat dorodango/sys-def.scm
  (define-system dorodango
    (version 0)
    (depends spells srfi)
    (documentation "doc" ("Readme.txt" -> "README")))

  % cat spells/sys-def.scm
  (define-system spells
    (version 0)
    (depends srfi)
    (documentation "doc")
    (libraries "spells"))

- Destinations: This is where systems get installed to. Each destination
  has a root directory and associated rules that map the files from each
  category of a system to a certain (sub)directory. For example, for a
  per-user configuration, the rules might say:

  - Put documentation under "doc/<system-name>-<version>/"
  - Put scheme libraries under "libraries"

  For distribution packaging, the rules would be different to comply
  with the Distribution's policy (and/or FHS):

  - Put documentation under
    "share/doc/libr6rs-<system-name>-<version>/"
  - Put scheme libraries under
    "lib/r6rs-libraries"

- Repositories: A directory containing:

  - A file describing all available systems (name, version), each along
    with the path to the bundle it is contained in.

  - The bundle files (or directories) referred to by the above
    "inventory".

Commonly, a repository will served via HTTP, but it might as well just
be on a local filesystem.

[0] From Wikipedia <http://en.wikipedia.org/wiki/Dorodango>:

      Dorodango is a Japanese art form in which earth and water are
      molded to create a delicate shiny sphere, resembling a marble or
      billiard ball.

    I think the fact that the result of excercising Dorodango is
    essentially a "polished mudball", makes this quite suitable a name
    for a Package manager ;-)

Start the flames!

(system (<name> . <version>)
  <other-stuff> ...)

This also makes apparent the possibility of hierarchical names, but I'm
not gonna worry about that for now.

The file name is now also not fitting any more (not that I was that
happy about it before), how about "systems.doro"?

As for file name suffixes, how about some more mnemonic, such as
".scmp" or ".spkg" for "Scheme Package".