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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
