[php-maint] Bug#690409: php5-xcache: upgrades clobber local changes to xcache.ini

[intrigeri]

tags 690409 + unreproducible
tags 690409 + moreinfo
thanks

Hi,

This bug made it so that xcache is on the list of proposed removals
from testing. I would find this sad, so I investigated.
My analysis follows.

Stuart Prescott wrote (13 Oct 2012 22:47:15 GMT) :
> On upgrades from squeeze to wheezy, any configuration changes made
> by the local administrator to the xcache.ini are lost.

Squeeze's php5-xcache ships /etc/php5/conf.d/xcache.ini, while
Wheezy's ships /etc/php5/mods-available/xcache.ini and runs "php5enmod
xcache" in postinst. 

On my test system, after upgrading from Squeeze to Wheezy, I have both
the old configuration file and the new one in /etc/php5/conf.d/:

  10-pdo.ini -> ../mods-available/pdo.ini
  20-xcache.ini -> ../mods-available/xcache.ini
  xcache.ini

Both seem to be taken into account somehow, as shown by this warning:

  $ php
  Failed loading /usr/lib/php5/20090626/xcache.so:
  /usr/lib/php5/20090626/xcache.so: cannot open shared object file: No
  such file or directory

Looking further, it looks like variables set in the old xcache.ini
take precedence over those set in the new 20-xcache.ini symlink: if
I set xcache.size, in the old xcache.ini, to some value that does not
fit in my memory, I'm told:

  /dev/zero: Cannot allocate memory
  Failed creating file mapping
  PHP Fatal error:  Failed creating file mapping in Unknown on line 0
  PHP Fatal error:  XCache: Cannot create shm in Unknown on line 0

So, while I see a quite configuration files being mixed up in a quite
ugly way, I don't see changes made by the administrator being lost
along the way. Stuart, what did I miss?

Meta: unless we are shown in more details how configuration changes
are lost during the upgrade, I think this bug should be retitled
"should handle conffile location changes" and its severity downgraded
to important. But given I'm no expert in that field, and could very
well have missed something, I'm merely tagging unreproducible and
moreinfo to start for now.

> Moving conffiles should be done carefully using tools like
> dpkg-maintscript-helper mv_conffile to ensure that local changes are
> not lost.

FWIW, a few /var/lib/dpkg/info/php5-*.postinst have the logics to do
so, and could probably be used as inspiration sources. These code
snippets look all similar, so they might be automatically generated by
some packaging helper.

> Note that the exact conffile shipped in squeeze embeds the entire
> path to the extension (which it probably should not have done)
> meaning that the conffile needs to be updated in some other policy
> compliant fashion....

Changing the zend_extension's value to the new path, if and only if
its original value is still the one shipped in Squeeze, looks doable.
But perhaps we want to avoid hard-coding this path once again?
Any idea how this could be achieved? (I guess the maintainers did not
do it that way simply by choice, so I guess it's not trivial.)

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc