Re: Is declaring correct deps/conflicts for versions not in stable really no longer needed?
> > 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 :).
Reply to: