Re: Adding version constraints in dependencies to avoid bugs
Santiago Vila <sanvila@unex.es> writes:
> I was the one who asked for these build-depends to become versioned.
> My rationale for that is in policy when it says that "it must be
> possible to build the package when the build-dependencies are met".
> If this is not the case it may be argued that the source package is
> buggy even if we do not experience the problem ourselves in testing.
Yes, there was definitely a bug. The bug was then fixed... in the
dependency. So now there's no longer a bug. :)
I don't think it's the best reading of Policy to say that a package must
guarantee that none of its build dependencies are buggy in a way that
would prevent the package from being built. This would require a lot of
awkward work, and somewhat more to the point, people *aren't* doing this
and historically *haven't* done this, so it's not a meaningful invariant
for the distribution.
In general, I recommend not worrying too much about any bug state that
occurred transiently during the development of a new stable release and
was resolved later in that same development process. I think we can
assume that people running testing or unstable will regularly upgrade
packages and, if they hold packages at old versions that aren't in stable,
will expect some breakage from doing so. (It's different if the breakage
was in a stable release, although even there it's better to fix the bug in
the actually broken package and then expect stable users to apply
updates.)
We make strong guarantees about stable as a coherent distribution; we do
not make such guarantees about any frozen moment of testing, let alone
unstable.
> After all, Debian-derived distros like Ubuntu, for example, could
> inherit this bug from us if they fork unstable and not testing.
If they do that, they will have to deal with problems like this. Comes
with the territory.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: