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

[Steve Langasek]

On Tue, Feb 06, 2007 at 12:05:46PM +0100, Romain Beauxis wrote:
> 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.

Hmm, unfortunate.

> 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.

No, policy requires that the *file* be stored in /etc, not a symlink *to*
the file.  So this is still a policy violation.

Under the circumstances, I would be willing to grant an etch-ignore
exception for the file location.  If the location of the file is still
causing upgrade errors (which seems possible, since the symlinks under
/etc/mediawiki1.7 are not conffiles and therefore may overwrite a user's
config), that would be more than just a technicality, and I wouldn't grant
an etch-ignore exception for that.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon at debian.org                                   http://www.debian.org/