On Thu, 17 Jan 2013 21:51:32 +0100 Wouter Verhelst <wouter@debian.org> wrote: > On Thu, Jan 17, 2013 at 09:34:16AM +0100, Johannes Schauer wrote: > > Hi, > > > > On Thu, Jan 17, 2013 at 08:33:57AM +0100, Wouter Verhelst wrote: > > > If wanna-build is updated to support these two fields, then I imagine > > > it can run the bootstrapping dependency algorithm. While you wouldn't > > > want to upload a package to the debian.org archive when the > > > architecture is as yet incomplete, the same isn't true for the > > > debian-ports.org archive. Much (most?) bootstrapping is going to be cross-building which wanna-build doesn't do. Native builds are not possible for new architectures and the many iterations inherent in bootstrapping will suit cross-building better when working with emulation or models. > It already needs to do build-dependency tracking, marking packages as > "can't be built yet because build-depends aren't there yet" all the > time. That's exactly the sort of thing you need to be doing, no? Not quite. Many dependency resolvers exist (for better or worse, we have a lot of choice), wanna-build isn't a particularly lightweight resolver as it isn't designed to be just a resolver. wanna-build isn't designed to do cross-building and there are other tools which have already been patched to improve their cross-build support (like sbuild and rebuildd). Not all Debian build tools need to do any real work due to the bootstrapping fields - most of the main tools can simply allow the fields and ignore them. > > After all profile built packages successfully rebuilt > > fully, *all* source packages of the strongly connected component are > > rebuilt. This is to make sure that every source package was built once > > with all build dependencies available. > > If you have enough information on what a package needs to build > properly, you wouldn't need to do this. > > But I agree that's a pretty big "if". ... and the information changes with every upload of every package, even ones which weren't part of the dependency chain at the previous version ... (which makes cross-building even more likely just to have a chance of new architectures / emulated architectures keeping up) > Your build profiles are essentially creating additional "variants" of a > particular binary package. .. variants which do not have to be uploaded anywhere in particular, neither ftp-master not debian-ports. Once bootstrapping is complete, all the packages are going to be rebuilt with none of the bootstrapping profiles enabled anyway. The typical problem with these variants is that almost nobody else is using this particular configuration of the package and even upstream probably rarely test their package in this mode. Packages which depend on the modified package will almost certainly never have been tested against the changes made for bootstrapping purposes. There are significant risks in letting bootstrapping packages out of a tightly controlled bootstrapping chroot / machine. It's not just about build-depends, it is about not getting into the situation where bugs get reported to the main package BTS which relate solely to one or other package being in a bootstrap-only configuration. These might not be so hard to identify in the package being modified but when packages which depend on that package start misbehaving, bugs get a lot harder to triage. Let's not make work for people if we can avoid it, especially if those people are maintaining packages which aren't directly involved in bootstrapping. Bootstrapping support can be implemented without explicit support in the main archive software (other than allow-and-ignore) and, personally, I think that is the correct way to manage things. Only certain tools need to be modified and we should resist the temptation to generalise a mechanism which is likely to cause confusion and bugs in previously working software. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpCZF2Gvqz4Q.pgp
Description: PGP signature