On Thu, Aug 31, 2006 at 08:28:09AM +0200, Stefano Zacchiroli wrote: > On Wed, Aug 30, 2006 at 05:21:23PM -0700, Steve Langasek wrote: > > 2) please try to check whether this new upstream version includes any > > regressions in the set of architectures supported for native compiling. The > > latter has happened before in the past, and it would be unpleasant to have > > to deal with such a transition at this point in the release cycle. > > Thanks for the feedback. > > Just to move in advance: what do you suggest to do in case (2) is > actually the case?
Maybe going to a more generic usage of arch: all bytecode, like the spamoracle case. This would not work for C bindings, but in all the other case, it would simply mean that if a native arch dissapears, a bunch of binary packages would not build on said arches, but that would be just fine, since the arch:all version would be in the archive, and seamlessly replace it. We would need to purge older versions of the packages out of the archive though, and the real problem are those libraries which hold C bindings. We would need to more strongly list them, and run a rebuild of those on those arches, but maybe since it is targeted at those arches, it would be possible to do a manual run or something. Ideally, if buildd's where able to build from the archive *and* already built packages, and handle the (build-)dependency tree, including those package already built but not uploaded or those scheduled for build, it would make this issues much easier. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
