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