| Frank Küster 2006-01-13, 10:44 pm |
| Steve Langasek <vorlon@debian.org> wrote:
> On Tue, Jan 10, 2006 at 11:08:14AM +0100, Frank K=FCster wrote:
>
>
> <sigh> No, buildds don't magically go from believing a dependency is
> satisfied, to believing it's not satisfied, and back again. If the probl=
em
> has disappeared, it's due to human intervention.
Reverting the argument, this means that the buildd only believed the
dependency was satisfied while in fact it wasn't after a human's
intervention. I don't believe that buildd admins deliberately did
this... There might have been some bug causing this, but hardware
failures also sometimes manifest as apparently "random" behavior.
And, by the way, I think that evidence is more for the view that it
wasn't a complete package that was missing, but rather only particular
files - at least this was the case previously when mysql-dfsg-5.0
failed.=20
>
>
> Then you haven't been looking at buildds for very long.
Fortunately not, since my packages hardly suffered FTBFSes, and the ones
they caused where of a different nature.
> Historically such
> problems were unpleasantly frequent on buildds due to a combination of bu=
ggy
> postrm scripts, and a bug in dpkg's rollback support when calling dpkg
> --purge for a package in the "installed" state. I believe the dpkg bug is
> fixed now, but a) I could be wrong, and b) there may be other bugs in the
> world.
Ah - can you point me to something to read about this? How can it be
architecture-specific, or host-specific?
Regards, Frank
--=20
Frank K=FCster
Inst. f. Biochemie der Univ. Z=FCrich
Debian Developer
|