[Pkg-mediawiki-devel] Bug#409434: Can reports of serious policy violations be downgraded to important?

[Romain Beauxis]

Le mardi 6 février 2007 02:47, Philippe Cloutier a écrit :
> >If you wish to add a RC bug more to debian, please ask to the release
> > managers if they feel that this should be solved for debian etch.
>
> Release team: I believe that #388616 should be upgraded back to serious.
> Please state that you agree with Romain if the report shouldn't be
> upgraded back to serious.

Ok, right I acknowledge the answer from the release team.

Now here is my anwser:
I do not feel apropriate to correcet this bug and here is why :
* The configuration file is not located in /etc and this is a policy 
violation, that is a fact. However, this configuration file is linked in /etc 
so that the administrator can locate it when he needs it. 
* Reports claiming that their configuration files had been deleted by update 
were either users of the previous packaging or users that had a wrong 
documentation. Since those bugs were posted, I corrected documentation. Also, 
on a fresh install, messages after install clearly ask for puting this file 
in /var/lib/mediawiki1.7
* The reason why I did this rely on this header, on the fresh configuration 
file:
"if( defined( 'MW_INSTALL_PATH' ) ) {
        $IP = MW_INSTALL_PATH;
} else {
        $IP = dirname( __FILE__ );
}"
From this point, the $IP, which is later taken as include path, 
reflects /etc/mediawiki1.7 as soon as the configuration file is located 
in /etc: php resolves dirname by the real directory name and not the name for 
the directory of the link.
* I choosed to put the file to /var/lib because I misread the policy, and 
because, under this bad assumption, I choosed the solution which involved the 
less patching. Obviously, adding a 
define(MW_INSTALL_PATH,"/var/lib/mediawiki1.7"° on top of the file is the 
good solution. It is also what is done in my next 1.9 package.

Now that I have cleared the origins of the bug, let's explain why I do not 
feel appropriate to resolve it:
* To me the violation is not that severe since the file is located in /etc 
after all. I understand that others may not think the same way, but that is 
my point.
* Let think a moment of what involved solving this issue. It involves:
  - Changing the patch for installation messages to reflect the /etc location
  - Adding a patch for defining this MW_INSTALL_PATH
  - Changing the documentation for reflecting this new path too
  - Changing the automated update script
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.

Now that would let a package for etch that would have a lot of debconf, script 
and code specialised for an issue that will not appear for any fresh install 
from the forthcoming debian stable and solves an issue that *I* feel not that 
important.

Now ok, I am not a blocker, if others come and say that it has to be solved 
I'll do it of course, but it is not my opinion. In particular, I would like 
to hear for Marc and perhaps the release team on what I wrote above.



Romain