Packaging

We need to improve packaging of MediaWiki and its associated services and tools. In a service-oriented architecture this becomes even more important, as a collection of services would be hard to install manually for third party users. This wiki page and the packaging mailing list are intended to help coordinate our efforts.

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

 * to be used by third party users, not WMF production
 * normal developers or deployers 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

FAQ

 * Is this meant for WMF deploys? -- No, the public repo is meant for third party users only. We can discuss a private repo & deb based deploys at WMF later.
 * How should this interact with Debian proper? -- I (Gabriel) think it would be great to contribute our packaging efforts directly to Debian, but if there are conflicts over policy or goals then we should prioritize our own goals over those of Debian. Making  set up & configure things like Memcached and Varnish might not fly so well with Debian, but would be very desirable for our users. Maybe we can find a solution that works well for both, let's see.