On Wed, Oct 17, 2012 at 11:48:17PM +0200, Matthias Klose wrote: > On 17.10.2012 21:49, Steve Langasek wrote: > > On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote: > >> Joerg Jaspert <joerg@debian.org> writes: > >>> Its for after wheezy, definitely. Also, there are some open issues to > >>> be solved for this to happen. The most important is being able to deal > >>> with arch all packages. And worse - arch all packages able to build > >>> only on certain architectures. But thats outside dak and my area. Goto > >>> the buildd/wanna-build people to help for that. > >> Also remeber, there are packages like cmucl that can only be built by the > >> same upstream release of itself and can currently survive in Debian > >> because the maintainer can upload a bootstrapped binary package along the > >> source > > Which is, frankly, an absurd requirement. Someone should fix this package > > to bootstrap properly, and if disallowing binary uploads forces the issue, > > that's a good thing. > you know better. The last one I did identify is eigenbase-resgen. Others > that come to mind are fpc, mlton, ... I am aware that other such packages exist. I just don't think we should support them if they can't be bootstrapped properly. > and adding new features / packages to the GNU toolchain requires manual > interaction for glibc/gcc uploads, which can't be done with source only > uploads. For the benefit of other readers on this list, the unstated context here is that there's a non-zero incidence of having to manually re-bootstrap compilers in the Ubuntu archive. The intermediate binaries used in this bootstrapping are discarded and never published to Ubuntu in order to conserve the "no binary uploads" rule, and this does impose some non-negligible overhead on the folks who tend these toolchain packages, due to the highly constrained build environment they have to work in. So yes, this is something that should be accounted for if Debian moves to a model where binary uploads are discarded and rebuilt. However, I suspect that for all the sensible cases, the proposal to add staged-build metadata (for bootstrapping circular build-dependencies on new ports) would be sufficient to make this problem go away too. But I'm a lot less concerned about the kinds of self-build-depending packages whose names are frequently taken in vain (raise your hand if you've ever tried to fix an RC bug in mlton). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature