[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: