Hi,
On Mon, Oct 15, 2012 at 09:48:32PM +0200, Platonides wrote:
On 15/10/12 19:57, Axel Thimm wrote:
I'm adding Patrick Uiterwijk to the Cc, as he's been attacking the package upgrade as well in the last weeks.
The main obstacle is a patch that ensured using a single codebase for multiple instances of mediawiki w/o touching/extending the LocalSettings.php configuration. The patch was splitting the use of $IP to two variables holding the code path and the data path respectively.
What patch are you using? How is it configured?
http://pkgs.fedoraproject.org/cgit/mediawiki.git/tree/mediawiki-1.16.2-commo...
It uses $IP as the code path and $DIR as the data path.
I've examined the current other solutions of doing so (e.g. as outlined on http://www.mediawiki.org/wiki/Manual:Wiki_family but none really provides a single source-multiple data solution w/ arbitrary install location for the instances and no special handling in LocalSettings.php.
You need some config switching somewhere. Perhaps the LocalSettings.php from MediaWiki POV could simply select from different subordinate LocalSettings.php
The patch worked by splitting the paths based on the current working directory (= instance path) vs a hard coded path for the mediawiki code).
Ideally we'd modify mediawiki in Fedora/RHEL to
o allow for concurrent installs of different mediawiki versions
May I ask why would you want this? Ideally, you shouldn't ever need anything other than the latest version.
In a pakaged distribution an upgrade of mediawiki w/o keeping the previous version would imply automatically running the mathing upgrade.php scripts on each instance.
First of all, I'd prefer if this is done by the user/admin of the instance. And next it may be that on a hosting wiki farm different users will want to upgrade at different times.
But that is more a packaging issue that can be easily solved with the current upstream code.
o allow simple imports/migration of unpackaged mediawiki sites w/o changes to LocalSettings.php
The custom config at the user LocalSettings.php would need to reflect somewhere in your setup.
The user's LocalSettings.php doesn't need to be patched if the main code is to split the $IP variable (as done in the patch). The only thing left is how to setup the code path. The patch mentioned above uses a dirty hardwired path. A cleaner solution would allow to specify a different code path from the current working directory (but default to the current working directory to keep backwards compatible).
Would it be acceptable to mediawiki devs to split the use of $IP between code and data instances? In that case we should try to patch upstream into 1.20 this change, so all distributrions could simply use a central code/multiple data farm setup.
You mean as used for locating the files and as basis for the $wg*Directory variables? Seems doable easily. Any suggestion for the name of the "data $IP" ?
I used $DIR which is as bad as a name could had been, so I'll admit to zero creativity in name giving. :/ Something that reflects "instance", "data", (local) "config" etc.