On 12/01/2008, Bernhard R. Link wrote: > While a minimal chroot is good to test against missing > build-dependencies, a full real-world system is needed to test for > missing build-conflicts or configure switches to disable specific > autodetections. Sure. > So when you get disparities between a package build in a pure unstable > environment and on a buildd or a minimal chroot, that is not a bug in > the process but a bug in the package, which would not be catched when > only using buildds. Well, no. A “pure unstable environment” on a development box can have various configuration tweaks, differing from the defaults shipped with the packages, and that can impact the built binaries. > > disparities between (build-)dependencies' versions in case the > > package stays in NEW for some time. > > disparities can also happen with differently fast buildds or just by > the differences of the different architectures. Things should be able > to work with this. Maybe trying to limit these disparities might be interesting… > and then arguing how stupid those reasons are. And for source only > uploads please take a look at Ubuntu. I really hope we do not want to > go that path and up with totally unuseable packages (in the sense of > can't possibly ever do the single thing that package is there for) > ending up in stable releases. I don't see how requesting to have a binary along the source package ensures it has been tested, that upgrades and transitions are OK, etc. > > About the above: it's not like i386 is a rare architecture and it > > isn't possible to find some machines that could act as build > > daemons. > > There is a i386 buildd. Quite some people are uploading amd64 > packages. I personally usually only upload sparc binaries with my > sources. Sometimes the i386 buildd makes problems, sometimes another > buildd. Nothing specific with i386 here. Having a single point of failure is i386-specific as far as I can tell. Testing migration suffered from that. Are you saying that redundancy is totally useless and that one should just not care about it? -- Cyril Brulebois
Attachment:
pgpTiFGWNoyn1.pgp
Description: PGP signature