On Tue, Oct 12, 2004 at 12:49:47PM +0400, Nikita V. Youshchenko wrote:
> [attibution missing, probably Adam Conrad]
> > Perhaps so, but if we went out of our way to depend/conflict against
> > every broken package that's been in testing/unstable, package
> > relationships would be ridiculousy unwieldly. The very reason
> > testing/unstable exists is to weed out the bugs the best we can before a
> > stable release.
>
> I believe you are wrong.
> If package requires a version of another package greater than X, it should
> declare so in it's dependences, even if you are sure that next stable
> release will satisfy this automatically.
> 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]?
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.
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.
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.
--Jeroen
[1] This is just a random analogy, it's about the general idea, please
don't reply saying the analogy is not 100% correct
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
