Bug#567182: gcc: Please add libgcc1-udeb for Debian Installer

[Frans Pop <elendil@planet.nl>]

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.