Re: Php4 broken package ?
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 abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Reply to: