On Wed, 2003-03-26 at 02:20, Martin Wheeler wrote: > On Tue, 18 Mar 2003, Michelle Konzack wrote: > > > Am 11:53 2003-03-13 +0100 hat De Schrijver Peter geschrieben: > > > >During the install of dnsutils i saw php4 getting deinstalled, i have no > > >idea why. > Err ... on March 8th, Anthony Towns wrote: > > "glibc 2.3.1-14 should be entering testing "tomorrow" (sometime around 30 > hours from now, depending on your mirror). Along with it, some 800 other > source packages and all their binaries are expected to be updated. For > those of you running testing systems, please take care of the next few > days' upgrades, as a number of things *will* break. [...] > (NOTE: I have not done it myself. Anyone have any real-life experience?)
Yeah, I run testing systems and aptitude wanted to remove php4 and install php4-cgi instead to meet dependencies. After identifying that it was libc6 doing the evil deed (it has a "conflicts" with the testing version of php4), I just put libc6 on hold until they get it right. If you have already upgraded libc6 it is probably impossible to roll back to the previous version, as it won't exist in any repository any more. You will probably have to install the unstable php4, but this might force a cascade up updates you really don't want. What I don't fully understand is how this broken version of libc6 made it into testing. I thought nothing made it into testing with broken dependencies, but we currently have php4 depending on libc6, and libc6 conflicting with php4. From all reports the libc6 conflict is incorrect (I can't see how an explicit conflict like this would be wise), and if you force or remove it, php works fine. Testing normally rocks... it's more up to date than stable, and never has the "xxx is being updated... much breakage will ensue" problem. The only time testing seems to break is when someone forces something through, bypassing the normal automatic checks. I know people were complaining that testing is being held up by libc6 changes that couldn't get through because of unmet dependency requirements, but that's the _point_. Fix the damn dependency problems in unstable first, then it can propagate into testing, don't just shove the packages into testing and hope it resolves in there. (Apologies to all Debian Developers for above whinge...keep up the good work. I just wanted to throw in my 2c about the issue :-) -- ---------------------------------------------------------------------- ABO: finger [EMAIL PROTECTED] for more info, including pgp key ----------------------------------------------------------------------