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-comm…
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.
--
Axel.Thimm at
ATrpms.net