On Fri, Mar 02, 2007 at 09:18:05PM -0500, Stuart Anderson wrote: > >>> After further Sarge->Etchupgrade testing, it seems that this problem is > >>not > >>> an occasional fluke, but is at best non-deterministic. It needs to be > >>fixed > >>> properly as described in #404159.
> >>I don't understand what this has to do with sarge->etch upgrade testing > >>given that php5-ming was not in sarge, hopefully the maintainer can > >>explain > >>(and explain why this should be a release blocker). > I have a set of sarge backports of the packages that I have been using > on some production servers here. Technically, Steve is right in that > this doesn't apply to a sarge->etch upgrade, except on my servers (but > see below). > The remaining problem, is that the php package changed the scheme it > uses for identifying what modules to load. This happened around the > time -10 was uploaded, and the problem had not been seen (or at least > not recognized) then. The problem is that the php.ini file gets replaced > by the php package Uh, no, the php.ini file is only supposed to be replaced by the php package if the administrator *approves* of having the new version installed. That's the administrator's choice; if they choose to discard local changes to this config file from the sarge version, then yeah, any changes from php-ming are going to fall out, but that's hardly RC any more than it's RC when the same thing happens to an admin allowing a conffile to be overwritten. > and the addition of the phpN-ming module gets lost. Yes, but only as described above. > A 'dpkg-reconfigure phpN-ming' fixes the problem. This bug can be seen > in a testing->testing upgrade as well as the sarge->etch upgrade that is > only my problem. Bug 404159 is for this situation. Sure. It can also happen in an etch->lenny upgrade in the future. And yes, installing a per-extension file to the conf.d directory is absolutely preferable, but not RC in my opinion. > After doing a few more upgrades, I have seen this problem most of the > time, instead of the once which made me think it was just some kind of a > fluke. This is why I raised the severity. I didn't fix this back in > Deceember as I thought the old scheme was still adequate, and I didn't > want to be changing postinstalls so late in the release. Recent experience > has indicated it needs to be done anyway, so I have set aside some time this > weekend to prepare -11 packages. > Btw, if anyone can put in a good word for me with the DAM (I'm on the last > step of the NM process), I could save the time of hunting down my sponsor > to get the -11 packages uploaded. 8-) If you can post the URL for these packages to this bug, I'm sure someone will pick them up for you. Not that I'm opposed to putting in a good word with the DAM, but there's some difference of time scale that applies there... :) Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
