Packaging

We need to improve packaging of MediaWiki and its associated services and tools. The move to a service-oriented architecture makes this even more important, as a collection of services would be hard to install manually for third party users.

As a first step, we'd like to set up a public repository for WMF-developed software. Since we and many of our users are using Debian / Ubuntu systems starting with Debian packaging makes sense.

Public repository goals

 * normal developers can upload new packages
 * support stable releases with security updates, in particular for MW PHP code
 * usable with unattended-upgrades for automatic security update installation
 * support tracking of the latest WMF code (pretty much in sync with WMF deploys)
 * supports multiple versions per package (mini-dinstall for example)

Version in package name: apt-get install mediawiki-1.22
This is similar to the way kernels and language runtimes are packaged in Debian. The actual package has the major version in the package name. Then there is an additional meta package ('mediawiki-stable' for example) that depends on the latest stable package version. We probably don't need to support multiple major versions being installed in parallel, so we can use the same install path and config files for major versions. Major version packages conflict with all earlier major version packages.

Pros / Cons (feel free to tweak):
 * + easy to set up repository
 * + choice of tracking *latest* or a specific major release
 * 'mediawiki-stable' depending on the latest stable vs. install mediawiki-1.22
 * + less complicated to set up (no need to edit sources)
 * + no need to upload all other services etc to sections
 * - need to update packaging for major versions

Separate repository sections: mediawiki-1.22
In this version the package is always called 'mediawiki-stable' or the like, but which version this actually installs is determined by a repository section in /etc/apt/sources.list. Services like Parsoid, Rashomon, the PDF renderer, Mathoid etc would be in a separate section, as tying them to major MW PHP code releases does not make sense.

Pros / Cons (feel free to tweak):
 * + harder to accidentally upgrade to wrong version (accidentally track meta package)
 * - need to change sources for major version upgrade
 * - need separate section for services
 * - likely slower uptake on major version upgrades
 * - out of band communication to discover section names vs. package manager