On Sat, Dec 11, 2004 at 11:04:47AM +0000, Martin Michlmayr wrote: > Debian buildds. So just "doctoring" around a failure on a buildd by > building it in a different environment is not healthy in the long run > because we need to make sure that the buildd is capable of building > every package. I guess it's a good thing that we don't have maintainers building and uploading every single package in the archive (for at least one architecture) built in random environments, then. Oh wait, we do. Damn. Sarcasm aside, as I understand it, when there are multiple buildds for an architecture, there's no guarantee that they have identical environments *anyway*. Different packages are likely to be pre-installed in the buildd's chroot based on what was previously built on that buildd, and even the toolchain isn't necessarily identical from some of the posts I've seen on the topic of buildd failure (although that may have been a bug rather than a feature in those particular instances). If you're looking for perfectly repeatable builds from a known environment, there are a number of issues that need to be addressed before we start looking at manual uploads from a fairly clued individual. > In addition to this, there are often subtle problems that a package > may build, but not actually work. mips is an example where outdated > auto* scripts will lead to broken packages even though they build just > fine. In fact, we had such broken packages uploaded to the archive > because the people randomly compiling and uploading packages did not > know what they were doing! How will having a build succeed and be uploaded by a buildd admin solve this problem? If the package builds successfully, whether in a buildd or by hand, how will the uploader necessarily know that the package works? Or do buildd admins manually test all the functionality of every package their buildd makes? - Matt
Attachment:
signature.asc
Description: Digital signature