Romain Beauxis <[EMAIL PROTECTED]> 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)
