Thanks a lot for the quick reply. On Wednesday 27 January 2010, Matthias Klose wrote: > The patch itself looks ok, some other questions: > > - did you consider building the udeb from a separate source package, > build-depending on gcc-4.4-source?
No, I had not considered that. It's an option that has both advantages and disadvantages. The main disadvantage IIUC would be that we'd have to upload or binNMU that separate package every time gcc gets uploaded (for source compliance), which means it needs special tracking. I think for that reason it's a solution the Release team is generally not all that happy with. > - you don't need the package for m68k/hppa yet, but if you do build > for every architecture anyway, please don't build the package for > these archs, but libgcc2, libgcc4, and libgcc6 udebs. For my current patch that would mean also adding those udebs in the control.m4 file, correct? And to avoid needing to code exceptions in rules.d/binary-libgcc.mk it's probably simplest to just do that even if we don't use them. > - the patch should be prepared for gcc-4.5 as well. Will do if we decide on keeping it in gcc. > If there are additional constraints for uploads of the gcc-4.4 source > package during freeze times, I would prefer the approach to build the > udeb's from a separate source. No, given how the udeb will be used there are no additional restrictions. And now that migration to testing of udebs is supported in britney, there's also no longer any inconvenience there. (That was an important consideration why I've personally not pushed for this change in the past.) The only point for attention is that if gcc would get uploaded after the final upload of D-I for a release, FTP-masters will need to keep a copy of the version included in that D-I build [1]. But that's something that already also done for other packages and is an item for the D-I and Debian release managers, not for the gcc maintainers. Because of the above I think building the udeb from gcc is the most logical choice. Cheers, FJP [1] They create a special suite for that purpose. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
