I plan to EOL mediawiki for the EPEL releases for EL-4,5,6 due to packaging newer ones using mediawiki114,mediawiki115, mediawiki116.
There are several ways I can do this:
1) change mediawiki114 to replace mediawiki. Pros would allow people to keep a package on their system. COns most likely will break due to linking and changes in package.
2) put out a final mediawiki package with a "Please dont use." in README and %description.
3) just remove from system.
I need input and help on getting this done.
Thankyou.
On Tue, Nov 30, 2010 at 01:53:32PM -0700, Stephen John Smoogen wrote:
I plan to EOL mediawiki for the EPEL releases for EL-4,5,6 due to packaging newer ones using mediawiki114,mediawiki115, mediawiki116.
There are several ways I can do this:
- change mediawiki114 to replace mediawiki. Pros would allow people
to keep a package on their system. COns most likely will break due to linking and changes in package.
- put out a final mediawiki package with a "Please dont use." in
README and %description.
- just remove from system.
I need input and help on getting this done.
Thankyou.
I like option #1. Are you tracking this in a bugzilla somewhere? I would be happy to "help" insofar as testing this new package (the upgrade side-effects mainly).
.. however, I think this provides the best opportunity for a "better" upgrade path. We could document upgrade hurdles we find either on the wiki or in a README.Fedora file (or both).
Ray
On Tue, Nov 30, 2010 at 14:27, Ray Van Dolson rayvd@bludgeon.org wrote:
On Tue, Nov 30, 2010 at 01:53:32PM -0700, Stephen John Smoogen wrote:
I plan to EOL mediawiki for the EPEL releases for EL-4,5,6 due to packaging newer ones using mediawiki114,mediawiki115, mediawiki116.
There are several ways I can do this:
- change mediawiki114 to replace mediawiki. Pros would allow people
to keep a package on their system. COns most likely will break due to linking and changes in package.
- put out a final mediawiki package with a "Please dont use." in
README and %description.
- just remove from system.
I need input and help on getting this done.
Thankyou.
I like option #1. Are you tracking this in a bugzilla somewhere? I would be happy to "help" insofar as testing this new package (the upgrade side-effects mainly).
I have tried a couple of times to do #1. However they all ended up being very very delicate in that they only worked with a default install. As soon as I tried to make it work in a non-default way I ended up with broken links and a lot of hand fixing that would be needed either way.
At this point my best step is to parallel install mediwiki114 and mediawiki. Go through your config files and symbolic links and point to mediawiki114. Test. Repeat.
The second issue is that they are not 1:1 matches. I decided not to implement Axil's multihome patch because upstream had no interest in it and they pointed out it needed a more work for it to work well (for their definition of well). I am a) not a PHP developer and b) full up on other jobs so decided to take it out and implement a minimal patch set to deal with upstreams packaging style.
.. however, I think this provides the best opportunity for a "better" upgrade path. We could document upgrade hurdles we find either on the wiki or in a README.Fedora file (or both).
Ray
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Tue, Nov 30, 2010 at 03:33:43PM -0700, Stephen John Smoogen wrote:
On Tue, Nov 30, 2010 at 14:27, Ray Van Dolson rayvd@bludgeon.org wrote:
On Tue, Nov 30, 2010 at 01:53:32PM -0700, Stephen John Smoogen wrote:
I plan to EOL mediawiki for the EPEL releases for EL-4,5,6 due to packaging newer ones using mediawiki114,mediawiki115, mediawiki116.
There are several ways I can do this:
- change mediawiki114 to replace mediawiki. Pros would allow people
to keep a package on their system. COns most likely will break due to linking and changes in package.
- put out a final mediawiki package with a "Please dont use." in
README and %description.
- just remove from system.
I need input and help on getting this done.
Thankyou.
I like option #1. Are you tracking this in a bugzilla somewhere? I would be happy to "help" insofar as testing this new package (the upgrade side-effects mainly).
I have tried a couple of times to do #1. However they all ended up being very very delicate in that they only worked with a default install. As soon as I tried to make it work in a non-default way I ended up with broken links and a lot of hand fixing that would be needed either way.
At this point my best step is to parallel install mediwiki114 and mediawiki. Go through your config files and symbolic links and point to mediawiki114. Test. Repeat.
Ah. In light of your experiences then, it sounds like the parallel install is the way to go -- and then maybe down the road retire the parent mediawiki package after people have had a chance to adopt mediawiki114 and update their configurations.
The second issue is that they are not 1:1 matches. I decided not to implement Axil's multihome patch because upstream had no interest in it and they pointed out it needed a more work for it to work well (for their definition of well). I am a) not a PHP developer and b) full up on other jobs so decided to take it out and implement a minimal patch set to deal with upstreams packaging style.
All makes sense to me.
Do you have a bz# where you're tracking this so I could join to collaborate on testing? Alternately, I'll just keep an eye out for mediawiki114 packages to show up in epel-testing.
.. however, I think this provides the best opportunity for a "better" upgrade path. We could document upgrade hurdles we find either on the wiki or in a README.Fedora file (or both).
Ray
Ray
On Tue, Nov 30, 2010 at 15:49, Ray Van Dolson rayvd@bludgeon.org wrote:
On Tue, Nov 30, 2010 at 03:33:43PM -0700, Stephen John Smoogen wrote:
On Tue, Nov 30, 2010 at 14:27, Ray Van Dolson rayvd@bludgeon.org wrote:
On Tue, Nov 30, 2010 at 01:53:32PM -0700, Stephen John Smoogen wrote:
I plan to EOL mediawiki for the EPEL releases for EL-4,5,6 due to packaging newer ones using mediawiki114,mediawiki115, mediawiki116.
There are several ways I can do this:
- change mediawiki114 to replace mediawiki. Pros would allow people
to keep a package on their system. COns most likely will break due to linking and changes in package.
- put out a final mediawiki package with a "Please dont use." in
README and %description.
- just remove from system.
I need input and help on getting this done.
Thankyou.
I like option #1. Are you tracking this in a bugzilla somewhere? I would be happy to "help" insofar as testing this new package (the upgrade side-effects mainly).
I have tried a couple of times to do #1. However they all ended up being very very delicate in that they only worked with a default install. As soon as I tried to make it work in a non-default way I ended up with broken links and a lot of hand fixing that would be needed either way.
At this point my best step is to parallel install mediwiki114 and mediawiki. Go through your config files and symbolic links and point to mediawiki114. Test. Repeat.
Ah. In light of your experiences then, it sounds like the parallel install is the way to go -- and then maybe down the road retire the parent mediawiki package after people have had a chance to adopt mediawiki114 and update their configurations.
The second issue is that they are not 1:1 matches. I decided not to implement Axil's multihome patch because upstream had no interest in it and they pointed out it needed a more work for it to work well (for their definition of well). I am a) not a PHP developer and b) full up on other jobs so decided to take it out and implement a minimal patch set to deal with upstreams packaging style.
All makes sense to me.
Do you have a bz# where you're tracking this so I could join to collaborate on testing? Alternately, I'll just keep an eye out for mediawiki114 packages to show up in epel-testing.
The package was accepted and the mediawiki114 packages went into testing a while ago. I don't have any other bugzilla's involved
https://bugzilla.redhat.com/show_bug.cgi?id=633081 https://bugzilla.redhat.com/show_bug.cgi?id=633082 https://bugzilla.redhat.com/show_bug.cgi?id=633085
On 11/30/2010 05:05 PM, Stephen John Smoogen wrote:
The package was accepted and the mediawiki114 packages went into testing a while ago.
Really? for EL-5?
[root@hawk ~]# yum list --enablerepo=epel-testing mediawiki11* Loaded plugins: downloadonly Finished Error: No matching Packages to list
https://admin.fedoraproject.org/updates/search/mediawiki114
I guess I'd like to move to 1.16 when available. Anything special to the EPEL packages to note in addition to any MediaWiki notes on upgrading?
On Thu, Dec 2, 2010 at 14:00, Orion Poplawski orion@cora.nwra.com wrote:
On 11/30/2010 05:05 PM, Stephen John Smoogen wrote:
The package was accepted and the mediawiki114 packages went into testing a while ago.
Really? for EL-5?
I must have screwed something up. I thought I built them for 4->6
On Thu, Dec 02, 2010 at 02:22:15PM -0700, Stephen John Smoogen wrote:
On Thu, Dec 2, 2010 at 14:00, Orion Poplawski orion@cora.nwra.com wrote:
On 11/30/2010 05:05 PM, Stephen John Smoogen wrote:
The package was accepted and the mediawiki114 packages went into testing a while ago.
Really? for EL-5?
I must have screwed something up. I thought I built them for 4->6
Still not seeing these in epel-testing (EL-5). Stephen, is this the latest build we can test off of?
http://koji.fedoraproject.org/koji/buildinfo?buildID=204805
Ray
On Thu, 2 Dec 2010 14:22:15 -0700 Stephen John Smoogen smooge@gmail.com wrote:
On Thu, Dec 2, 2010 at 14:00, Orion Poplawski orion@cora.nwra.com wrote:
On 11/30/2010 05:05 PM, Stephen John Smoogen wrote:
The package was accepted and the mediawiki114 packages went into testing a while ago.
Really? for EL-5?
I must have screwed something up. I thought I built them for 4->6
For 4 and 5 you will need to make updates for them.
'fedpkg update' in the git dir set to whatever branch. Or https://admin.fedoraproject.org/updates/new/
in the web interface.
kevin
On Fri, Dec 10, 2010 at 12:11, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 2 Dec 2010 14:22:15 -0700 Stephen John Smoogen smooge@gmail.com wrote:
On Thu, Dec 2, 2010 at 14:00, Orion Poplawski orion@cora.nwra.com wrote:
On 11/30/2010 05:05 PM, Stephen John Smoogen wrote:
The package was accepted and the mediawiki114 packages went into testing a while ago.
Really? for EL-5?
I must have screwed something up. I thought I built them for 4->6
For 4 and 5 you will need to make updates for them.
'fedpkg update' in the git dir set to whatever branch. Or https://admin.fedoraproject.org/updates/new/
Thanks this was the step I was missing.
FYI, just tested moving from the base mediawiki package to mediawiki116. Upgrade process was as follows (in a nutshell):
Mediawiki install at /srv/syswiki/wiki/
1. Back up 2. mv /srv/syswiki /root/syswiki 3. Followed instructions in README.RPM to create a new wiki site (under /srv). Script to create symlinks worked great save for StartProfiler.php which didn't exist (it was StartProfiler.sample) 4. Copied my original LocalSettings.php back and modified "$IP" variable. 5. Reviewed RELEASE-NOTES for 1.15 and 1.16 for necessary config changes. 6. Changed to "maintenance" directory (now /srv/syswiki/wiki/maintenance) and ran the following:
MW_INSTALL_PATH=/srv/syswiki/wiki php update
7. Corrected issue with Ldap extension. 8. Fixed my Apache config which was aliasing the "skins" directory to /usr/share/mediawiki/skins
All is working great! Pretty easy.
I notice a few RPM-packaged extensions are tied to the original mediawiki package -- mediawiki-ParserFunctions for example.
Maybe /usr/share/mediawiki would be a good "generic" directory for non-version specific extension? Or should we get them repackaged per version?
For now I'll just install from source most likely.
Ray
On Mon, Dec 13, 2010 at 22:38, Ray Van Dolson rayvd@bludgeon.org wrote:
I notice a few RPM-packaged extensions are tied to the original mediawiki package -- mediawiki-ParserFunctions for example.
Maybe /usr/share/mediawiki would be a good "generic" directory for non-version specific extension? Or should we get them repackaged per version?
For now I'll just install from source most likely.
This was going to be my next thing to deal with. Some of the mediawiki extensions work with the latest and others do not. I am not sure of which :). I guess I need to ask the packaging committee on what best practice would be
On Tue, Dec 14, 2010 at 06:02:03PM -0700, Stephen John Smoogen wrote:
On Mon, Dec 13, 2010 at 22:38, Ray Van Dolson rayvd@bludgeon.org wrote:
I notice a few RPM-packaged extensions are tied to the original mediawiki package -- mediawiki-ParserFunctions for example.
Maybe /usr/share/mediawiki would be a good "generic" directory for non-version specific extension? Or should we get them repackaged per version?
For now I'll just install from source most likely.
This was going to be my next thing to deal with. Some of the mediawiki extensions work with the latest and others do not. I am not sure of which :). I guess I need to ask the packaging committee on what best practice would be
I kind of like the idea of a generic mediawiki extensions directory and configuring the package to "require" whichever version of MediaWiki it supports (this requirement could be satisfied by multiple versions).
The package then would either populate the version-specific mediawiki install's extensions directory with symlinks to the extension or some other clever trick to ensure it gets made available to the right versions automatically.
Maybe overengineered? Seems better than packaging extensions 3+ different times for each mediawiki package...
Ray
On Tue, 30 Nov 2010 14:49:42 -0800 Ray Van Dolson rayvd@bludgeon.org wrote:
On Tue, Nov 30, 2010 at 03:33:43PM -0700, Stephen John Smoogen wrote:
On Tue, Nov 30, 2010 at 14:27, Ray Van Dolson rayvd@bludgeon.org wrote:
On Tue, Nov 30, 2010 at 01:53:32PM -0700, Stephen John Smoogen wrote:
I plan to EOL mediawiki for the EPEL releases for EL-4,5,6 due to packaging newer ones using mediawiki114,mediawiki115, mediawiki116.
There are several ways I can do this:
- change mediawiki114 to replace mediawiki. Pros would allow
people to keep a package on their system. COns most likely will break due to linking and changes in package.
- put out a final mediawiki package with a "Please dont use." in
README and %description.
- just remove from system.
I need input and help on getting this done.
Thankyou.
I like option #1. Are you tracking this in a bugzilla somewhere? I would be happy to "help" insofar as testing this new package (the upgrade side-effects mainly).
I have tried a couple of times to do #1. However they all ended up being very very delicate in that they only worked with a default install. As soon as I tried to make it work in a non-default way I ended up with broken links and a lot of hand fixing that would be needed either way.
At this point my best step is to parallel install mediwiki114 and mediawiki. Go through your config files and symbolic links and point to mediawiki114. Test. Repeat.
Ah. In light of your experiences then, it sounds like the parallel install is the way to go -- and then maybe down the road retire the parent mediawiki package after people have had a chance to adopt mediawiki114 and update their configurations.
The second issue is that they are not 1:1 matches. I decided not to implement Axil's multihome patch because upstream had no interest in it and they pointed out it needed a more work for it to work well (for their definition of well). I am a) not a PHP developer and b) full up on other jobs so decided to take it out and implement a minimal patch set to deal with upstreams packaging style.
All makes sense to me.
Do you have a bz# where you're tracking this so I could join to collaborate on testing? Alternately, I'll just keep an eye out for mediawiki114 packages to show up in epel-testing.
Yeah, same here... so leave the existing mediawiki for now, push the new ones. Wait a while, and perhaps down the road we can nuke/replace the old one.
kevin
On Tue, Nov 30, 2010 at 12:53 PM, Stephen John Smoogen smooge@gmail.com wrote:
I plan to EOL mediawiki for the EPEL releases for EL-4,5,6 due to packaging newer ones using mediawiki114,mediawiki115, mediawiki116.
As far as I can see, 1.14 is not supported upstream. How do you propose handling security issues with that version? How will you handle the transition from 1.15 when that loses upstream support?
-Jeff
On Mon, Dec 6, 2010 at 13:38, Jeff Sheltren jeff@osuosl.org wrote:
On Tue, Nov 30, 2010 at 12:53 PM, Stephen John Smoogen smooge@gmail.com wrote:
I plan to EOL mediawiki for the EPEL releases for EL-4,5,6 due to packaging newer ones using mediawiki114,mediawiki115, mediawiki116.
As far as I can see, 1.14 is not supported upstream. How do you propose handling security issues with that version? How will you handle the transition from 1.15 when that loses upstream support?
I do not plan to handle security issues. The reason for 1.14 is that
a) I don't leave people hanging with the old version that was in EPEL. b) if mediawiki were removed from the repo people who HAD to have mediawiki114 had something.
-Jeff
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Mon, Dec 6, 2010 at 12:57 PM, Stephen John Smoogen smooge@gmail.com wrote:
On Mon, Dec 6, 2010 at 13:38, Jeff Sheltren jeff@osuosl.org wrote:
On Tue, Nov 30, 2010 at 12:53 PM, Stephen John Smoogen smooge@gmail.com wrote:
I plan to EOL mediawiki for the EPEL releases for EL-4,5,6 due to packaging newer ones using mediawiki114,mediawiki115, mediawiki116.
As far as I can see, 1.14 is not supported upstream. How do you propose handling security issues with that version? How will you handle the transition from 1.15 when that loses upstream support?
I do not plan to handle security issues.
Are other people worried about EPEL shipping/maintaining packages with known security issues? Even with a big "DON'T USE THIS PACKAGE" in the package description and/or README file, I'm sure that there will be those that install it. This doesn't seem like a very responsible thing for us to do in general.
-Jeff
On Mon, Dec 06, 2010 at 01:55:26PM -0800, Jeff Sheltren wrote:
On Mon, Dec 6, 2010 at 12:57 PM, Stephen John Smoogen smooge@gmail.com wrote:
On Mon, Dec 6, 2010 at 13:38, Jeff Sheltren jeff@osuosl.org wrote:
On Tue, Nov 30, 2010 at 12:53 PM, Stephen John Smoogen smooge@gmail.com wrote:
I plan to EOL mediawiki for the EPEL releases for EL-4,5,6 due to packaging newer ones using mediawiki114,mediawiki115, mediawiki116.
As far as I can see, 1.14 is not supported upstream. How do you propose handling security issues with that version? How will you handle the transition from 1.15 when that loses upstream support?
I do not plan to handle security issues.
Are other people worried about EPEL shipping/maintaining packages with known security issues? Even with a big "DON'T USE THIS PACKAGE" in the package description and/or README file, I'm sure that there will be those that install it. This doesn't seem like a very responsible thing for us to do in general.
-Jeff
I would call it more realistic than irresponsible. We can't make someone remove a package from their system, and we by and large don't have the resources to backport security fixes into something as complicated as Wikipedia.
I guess the argument is Obsoleting wikipedia and wikipedia114? So would automatically breaking a user's installation be preferrable to leaving them open to attack? Does EPEL advertise that it provides completely secure packages or 'best-effort' only and it's up to individual administrators to keep their eyes on such things?
I think the latter is the only realistic approach "in general". And even in this specific case, I'd rather not see my (internal) Mediawiki 1.14 install broken automatically by an upgrade to 1.15.
Too bad there's not some slick way to automatically notify users via email. Opt-in of course, and accessible via pkgname-epel-users@fp.o or something. :)
Jeff does bring up a good point though -- I imagine there are other packages that would fall under this umbrella (gallery2?).
Just my $0.02.
Ray
epel-devel@lists.fedoraproject.org
-
Jeff Sheltren -
Kevin Fenzi -
Orion Poplawski -
Ray Van Dolson -
Stephen John Smoogen