Axel Thimm and Fedora Release Engineering,
I'm looking for the person in charge of packaging MediaWiki for Fedora. From the recent changelog, it looks like Axel is that person.
I'd like to start working with you to get the MediaWiki 1.19 series packaged for Fedora and use that as a basis for working with other RPM-based distributions.
Even though MW 1.20 is about to be released, I'd like to use 1.19 so that we can make it an LTS release and collaborate on supporting it.
We (a group of MediaWiki developers, especially Platonides) have been working with the Debian developers to get 1.19 into Wheezy and have been able to help them resolve some issues more quickly because of our familiarity with MediaWiki.
I hope that you'll see the mutual benefit that could come from collaborating on MediaWiki packaging.
What do we need to do to get the process started?
Hi Mark,
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.
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.
Ideally we'd modify mediawiki in Fedora/RHEL to
o allow for concurrent installs of different mediawiki versions o allow simple imports/migration of unpackaged mediawiki sites w/o changes to LocalSettings.php
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.
Thanks, Axel.
On Sun, Oct 14, 2012 at 03:52:57PM -0400, Mark A. Hershberger wrote:
Axel Thimm and Fedora Release Engineering,
I'm looking for the person in charge of packaging MediaWiki for Fedora. From the recent changelog, it looks like Axel is that person.
I'd like to start working with you to get the MediaWiki 1.19 series packaged for Fedora and use that as a basis for working with other RPM-based distributions.
Even though MW 1.20 is about to be released, I'd like to use 1.19 so that we can make it an LTS release and collaborate on supporting it.
We (a group of MediaWiki developers, especially Platonides) have been working with the Debian developers to get 1.19 into Wheezy and have been able to help them resolve some issues more quickly because of our familiarity with MediaWiki.
I hope that you'll see the mutual benefit that could come from collaborating on MediaWiki packaging.
What do we need to do to get the process started?
Any time you have "one overriding idea", and push your idea as a superior ideology, you're going to be wrong. ... The fact is, reality is complicated -- Linus Torvalds http://hexm.de/mc
On 15 October 2012 18:57, Axel Thimm Axel.Thimm@atrpms.net wrote:
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.
Slightly OT for this list, but let me note that us tarball users would also be really pleased with a more supported and less ad-hoc method to do wikifarms, or even just infrastructure to this end.
- d.
On 15/10/12 19:57, Axel Thimm wrote:
Hi Mark,
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?
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
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.
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.
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" ?
On 15 October 2012 20:48, Platonides platonides@gmail.com wrote:
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.
Caution when upgrading wikis springs to mind, particularly if you have your own local extensions.
Different selections of extensions on a set of wikis, even if they have the same MW version, is useful also.
- d.
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.
On 16/10/12 02:42, Axel Thimm wrote:
Hi,
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.
We should have used $IP explicitely in a few places instead of relative paths. Do note that
if ( file_exists( 'config/LocalSettings.php' ) ) {
if ( file_exists( $DIR . 'config/LocalSettings.php' ) ) {
is wrong ($DIR doesn't contain a trailing slash)
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).
Basing it on variables set in .htaccess/server config may be the way to go. You could almost set $IP that way defining MW_INSTALL_PATH on php.ini
Ideally we'd modify mediawiki in Fedora/RHEL to 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.
IMHO upgrading the package should automatically run update.php on all the instances linked to it (which in turn needs some sort of central registry, how are you handling that?).
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).
I see.
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.
We could use MW_DATA_PATH for the define. Not sure about the variable.
For opensuse I've developed scripts which allows simple installation and updates of several mediawiki instances. You could have a look at the scripts in https://build.opensuse.org/stage/package/files?package=mediawiki&project...
There is makealias.sh, which builds up a symlinked structure and suggests an apache configuration (based on mediawiki's short urls. The suggested config also tries to seperate the individual installations completly by setting some php-parameters. All created wikis are listed in /etc/mediawiki-installations to be used by update.sh which incorporates the single updates and some service-works, depending on the version upgrades.
There are no patches needed to operate the wiki (there is only one patch for an upload problem included, which should be removed when I'm updateing to release 1.20).
Johannes
On 16/10/12 13:32, Johannes Weberhofer wrote:
For opensuse I've developed scripts which allows simple installation and updates of several mediawiki instances. You could have a look at the scripts in https://build.opensuse.org/stage/package/files?package=mediawiki&project...
There is makealias.sh, which builds up a symlinked structure and suggests an apache configuration (based on mediawiki's short urls. The suggested config also tries to seperate the individual installations completly by setting some php-parameters. All created wikis are listed in /etc/mediawiki-installations to be used by update.sh which incorporates the single updates and some service-works, depending on the version upgrades.
Johannes
Very interesting. Note that in README.DISTRIBUTION: - MediaWiki works with some more dbs than mysql and postgresql. - Apache requeriment is not a strict one, pretty much any web server with php support would work. - $wgDisableUploads is an old variable (MW < 1.5.0). It is $wgEnableUploads now. - The bottom urls should point to www.mediawiki.org
The makealias.sh looks quite pretty but
Alias /wiki/common $TARGETDIR/webroot/common
We don't have a common folder (we do have skins/common but that's included in skins alias)
You are mapping both script paths and documents inside /wiki What would happen if I wanted to create an article named 'skins'? How would you forbid robots accessing history urls but allow normal pages?
I'd prefer the classical /w /wiki setup.
It's a bit obscure how $MW_SYSDIRS, $MW_LINKFILES, are created in admintools/files in the spec file. (you're also symlinking more files than needed, but it's better to symlink too much than too few)
I'm a bit intrigued pn how it is finding the right LocalSettings.php, though.
PS: Is is possible to clone the repository of the package specs? Although there's clearly a repository backend, I was unable to find it.
Platonides,
thank you very much for your review! I'll incorporate some changes in the next release.
Am 16.10.2012 18:30, schrieb Platonides:
On 16/10/12 13:32, Johannes Weberhofer wrote:
For opensuse I've developed scripts which allows simple installation and updates of several mediawiki instances. You could have a look at the scripts in https://build.opensuse.org/stage/package/files?package=mediawiki&project...
There is makealias.sh, which builds up a symlinked structure and suggests an apache configuration (based on mediawiki's short urls. The suggested config also tries to seperate the individual installations completly by setting some php-parameters. All created wikis are listed in /etc/mediawiki-installations to be used by update.sh which incorporates the single updates and some service-works, depending on the version upgrades.
Johannes
Very interesting. Note that in README.DISTRIBUTION:
- MediaWiki works with some more dbs than mysql and postgresql.
- Apache requeriment is not a strict one, pretty much any web server
with php support would work.
That's true, I've added some more text to the file
- $wgDisableUploads is an old variable (MW < 1.5.0). It is
$wgEnableUploads now.
Thank you for recognize that. I've corrected the text.
- The bottom urls should point to www.mediawiki.org
Didn't check that for a while. Modified it.
The makealias.sh looks quite pretty but
Alias /wiki/common $TARGETDIR/webroot/common
We don't have a common folder (we do have skins/common but that's included in skins alias)
Hmm... Don't know why I have added that. I'm quite sure, there was some reason; I've removed it, as it's definitely no longer needed
You are mapping both script paths and documents inside /wiki What would happen if I wanted to create an article named 'skins'?
All Pages start with an uppercase-letter, so there should be no problem related to that.
How would you forbid robots accessing history urls but allow normal pages?
I'd never thought about that; I've seen that there is '<meta name="robots" content="noindex,nofollow" />' included in HTML, so robots shouldn't index older versions.
I'd prefer the classical /w /wiki setup.
I don't prefer none of the setups; for some reason I decided to use this setup some years ago.
It's a bit obscure how $MW_SYSDIRS, $MW_LINKFILES, are created in admintools/files in the spec file. (you're also symlinking more files than needed, but it's better to symlink too much than too few)
That's created in the spec files; I had some problems with the updates around MW 1.17 when there were some major changes regarding the load.php and api.php; those things could be simplified I think.
I'm a bit intrigued pn how it is finding the right LocalSettings.php, though.
Pleas explain me more...
PS: Is is possible to clone the repository of the package specs? Although there's clearly a repository backend, I was unable to find it.
It's a opensuse build service repository. To download it, you must install the osc client from the repository in http://download.opensuse.org/repositories/openSUSE:/Tools/ (it supports lot of OS); There is a manual at http://en.opensuse.org/openSUSE:OSC Once you have installed the client, you can execute "osc co server:php:applications mediawiki".
Best regards, Johannes
On 17/10/12 10:55, Johannes Weberhofer wrote:
Platonides,
thank you very much for your review! I'll incorporate some changes in the next release.
I'm glad you liked it :)
The makealias.sh looks quite pretty but
Alias /wiki/common $TARGETDIR/webroot/common
We don't have a common folder (we do have skins/common but that's included in skins alias)
Hmm... Don't know why I have added that. I'm quite sure, there was some reason; I've removed it, as it's definitely no longer needed
It may have been in the root folder a long time ago.
You are mapping both script paths and documents inside /wiki What would happen if I wanted to create an article named 'skins'?
All Pages start with an uppercase-letter, so there should be no problem related to that.
Unless you have $wgCapitalLinks = false; (yes, I'm playing devil's advocate)
How would you forbid robots accessing history urls but allow normal pages?
I'd never thought about that; I've seen that there is '<meta name="robots" content="noindex,nofollow" />' included in HTML, so robots shouldn't index older versions.
Only after they downloaded the page and made you parse it. Whereas if forbidden in robots.txt, they don't even request it.
I'd prefer the classical /w /wiki setup.
I don't prefer none of the setups; for some reason I decided to use this setup some years ago.
Having the articles and scripts in the same location leads to issues (even more if they are also at the root, which thanksfully you're not doing).
I'm a bit intrigued pn how it is finding the right LocalSettings.php, though.
Pleas explain me more...
You have a mediawiki in /var/www/foo and another in /var/www/bar, how is it choosing between /var/www/foo/LocalSettings.php and /var/www/bar/LocalSettings.php ? Looks like it would always load /usr/share/mediawiki/LocalSettings.php ...
Am 17.10.2012 11:43, schrieb Platonides:
On 17/10/12 10:55, Johannes Weberhofer wrote:
Platonides,
thank you very much for your review! I'll incorporate some changes in the next release.
I'm glad you liked it :)
The makealias.sh looks quite pretty but
Alias /wiki/common $TARGETDIR/webroot/common
We don't have a common folder (we do have skins/common but that's included in skins alias)
Hmm... Don't know why I have added that. I'm quite sure, there was some reason; I've removed it, as it's definitely no longer needed
It may have been in the root folder a long time ago.
You are mapping both script paths and documents inside /wiki What would happen if I wanted to create an article named 'skins'?
All Pages start with an uppercase-letter, so there should be no problem related to that.
Unless you have $wgCapitalLinks = false; (yes, I'm playing devil's advocate)
How would you forbid robots accessing history urls but allow normal pages?
I'd never thought about that; I've seen that there is '<meta name="robots" content="noindex,nofollow" />' included in HTML, so robots shouldn't index older versions.
Only after they downloaded the page and made you parse it. Whereas if forbidden in robots.txt, they don't even request it.
I'd prefer the classical /w /wiki setup.
I don't prefer none of the setups; for some reason I decided to use this setup some years ago.
Having the articles and scripts in the same location leads to issues (even more if they are also at the root, which thanksfully you're not doing).
I'm changing to that with the next release.
I'm a bit intrigued pn how it is finding the right LocalSettings.php, though.
Pleas explain me more...
You have a mediawiki in /var/www/foo and another in /var/www/bar, how is it choosing between /var/www/foo/LocalSettings.php and /var/www/bar/LocalSettings.php ? Looks like it would always load /usr/share/mediawiki/LocalSettings.php ...
Do you mean the maintenance scripts on the command line or the hosted sites?
Best regards, Johannes
On Mon, 15 Oct 2012 10:57:52 -0700, Axel Thimm Axel.Thimm@atrpms.net wrote:
Hi Mark,
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.
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.
That's just how it's done. Even if that special handling in LocalSettings.php is something like: require_once( $_SERVER['DOCUMENT_ROOT'] . '/LocalSettings.php' );
I haven't yet seen I proposal I liked on how to let MediaWiki know where the alternate location for config is.
Ideally we'd modify mediawiki in Fedora/RHEL to
o allow for concurrent installs of different mediawiki versions o allow simple imports/migration of unpackaged mediawiki sites w/o changes to LocalSettings.php
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.
I guess a $DP that you can optionally use from LocalSettings.php which defaults to $IP for everyone and is simply used in place of $IP for various default values might not be that objectable.
Thanks, Axel.
On Sun, Oct 14, 2012 at 03:52:57PM -0400, Mark A. Hershberger wrote:
Axel Thimm and Fedora Release Engineering,
I'm looking for the person in charge of packaging MediaWiki for Fedora. From the recent changelog, it looks like Axel is that person.
I'd like to start working with you to get the MediaWiki 1.19 series packaged for Fedora and use that as a basis for working with other RPM-based distributions.
Even though MW 1.20 is about to be released, I'd like to use 1.19 so that we can make it an LTS release and collaborate on supporting it.
We (a group of MediaWiki developers, especially Platonides) have been working with the Debian developers to get 1.19 into Wheezy and have been able to help them resolve some issues more quickly because of our familiarity with MediaWiki.
I hope that you'll see the mutual benefit that could come from collaborating on MediaWiki packaging.
What do we need to do to get the process started?
Any time you have "one overriding idea", and push your idea as a superior ideology, you're going to be wrong. ... The fact is, reality is complicated -- Linus Torvalds http://hexm.de/mc
mediawiki-distributors@lists.wikimedia.org