Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The way I see it, there will be the following elements:
> - a (set of) Bzr repository holding the package sources.
> - a tool that will build tarballs from those sources.
> - an area where those tarballs are stored, along with some metadata
>   (think Debian repository).
> - a tool that can scan such repositories and downlooad packages from
>   them, obeying dependencies (think APT).
> - a tool that can install/activate/uninstall a given package, ... (think
>   DPKG).  This last one is what I tried to write when I wrote install.el
>   many moons ago.

Here are the pieces to the puzzle from my initial brainstorming:

* An index file contains a alist mapping projects to DVCS
  repositories. This would be manually curated. Adding a project would
  just be done by adding an entry to this file.

* A function that builds packages for every version in the repository of
  each project. A version is defined by a tag matching a given pattern.

* The packages are deployed to an archive source, which is publicly
  available over HTTP.

* Currently package.el can perform the last two points from your list
  (scan/download/dependencies and install/activate/uninstall).

The attached file implements the server-side maintenance, albeit in a
rough manner. It's limited to single-file packages kept in git
repositories, simply because that's what I'm personally familiar with,
though I don't think supporting other DVCSes would be tricky at all.

I welcome comments on this. Once the server-side maintenance tool is
ready, I want to add support for multiple sources to the client-side
package.el, and once that's done supporting multiple install locations
on disk (as Tom has explained) would be the next step.

Right now the code is at http://github.com/technomancy/package.el,
though I've attached a copy of the relevant file.

-Phil