[Pkg-mediawiki-devel] Bug#388616: Making mediawiki FHS compliant

[Frank Küster]

Romain Beauxis <toots at rastageeks.org> wrote:

> Le samedi 24 février 2007 12:46, vous avez écrit :
>> > Ok, it was my understanding from previous comments in the bug history
>> > that this couldn't be done non-intrusively, because mediawiki would then
>> > look up the real directory and use that value for things that it
>> > shouldn't?
>>
>> In fact it's easy, it's a one-line patch
>
> And it is done in the awaiting mediawiki1.9 that is in the NEW queue.

But ithis will never make it into etch.

>> * Let think a moment of what involved solving this issue. It involves:
>>   - Changing the patch for installation messages to reflect the /etc
>> location

This is a documentation change.

>> - Adding a patch for defining this MW_INSTALL_PATH 

This is a one-line patch

>>   - Changing the documentation for reflecting this new path too

Again a documentation patch

>>   - Changing the automated update script

Which script is this?  Something that you wrote for the 1.7 -> 1.9
transition?  Or did upstream make the same change, and it's a transition
script by upstream?

>> And, perhaps the most important:
>>   - Add an updating code which detects wether the configuration is in /etc
>> or in /var and apply the good changes. Of course, in order not to blow
>> again any file, this script as to be started before the packages files are
>> copied.
>> - Also, you may add an advice to the administrator via debconf so 
>> that he is aware of this change in his configuration.

This is the code that I already sent in a previous mail.

> All of this is done straith forward and non intrusivly in mediawiki1.9: new 
> configuration files are created with this define, old are patched and since 
> the package uses a different location for its files, nothing more has to be 
> done.

Maybe we can use the code from this new transition script for 1.7, too?

> Frank, if you think this can be solved cleanly in mediawiki1.7 why don't you 
> just put up a complete patch instead of only one of the things to do ?
> If then it looks good, I would apply it happily.

Hm, I didn't do it mostly because if I send a complete patch, I don't do
that without exhaustive testing.  And this I didn't want to do on a bug
that had an etch-ignore tag.  But it seems the tag is based on
incomplete information about options to solve the bug, isn't it?

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)