> > Current situation is version of libapache-mod-php4 currently in > > testing does not work correctly with version of libc6 currently in > > testing. > > If a certain range of versions of a package was buggy, that is annoying, > but not a reason for all packages affected by it to depend on non-buggy > versions. Suppose a certain version of ext2fstools trashes my filesystem > on filenames of length 42, and my application uses this filename length > extensively, do I need to conflict with this version of ext2fstools[1]?
Although I agree that it is not possible (and sometimes is an absurd) to declare complete package relationships that will work correclty in any case, I think such deps should be declared whn possible. A good compromise is to declare relationship with any version of packages that have been in the archive since last stable release - at least in case when such relationships are either known by package maintainer a priori (as in this case - it was documented in changelog), or are found and reported by users. This costs a little effort, and makes mixed stable/testing/unstable systems more consistent. [I believe ability to run such systems without major problems is an important feature of debian] > The bug _was_ in glibc, and not in php. It is not the job of php to > force you to have a non-buggy glibc installed. This depends on point of view. If a library < X.Y does not provide a feature needed by a package, it's a common practice to make package depend on library (>= X.Y). Other packages, that don't need that library feature, don't need to depend on library (>= X.Y). The case with libapache-mod-php4 / glibc looks similar: glibc less than 2.3.2.ds1-17 does not provide neede functionality [due to a bug]. This affects libapache-mod-php4, but does no affect most (all?) other packages. > In this specific case, it must be prevented that in the end, a glibc and > a php that don't cooperate very well will be shipped with sarge. This > could be done by a suitable depends, or by making sure a newer non-buggy > glibc is really going to make testing. If we go futher this way, we may end with statement that versioned dependencies are not needed at all, because sooner or later needed version will enter testing, and the only thing is no ensure that this will happen before next stable release. > As one of the Release Managers (Steve Langasek) told you that the latter > will be taken care of, and there is even a RC bug on libc to make sure > this will happen (#259211), there is no risk this will be forgotten, so > indeed, the dependency is unneeded. IMHO this only means that this issue is not RC bug against libapache-mod-php4. But this does not mean that issue does not exist. Probably the issue is minor, and doesn't really need any attension. But system quality will be higher if this and similar issues will be avoided, and adding a versioned dep is not a high cost to pay for that :).
