> So, we should definitely do stripping of fonts to avoid overlap, but we > should also do it in the udebs themselves because the stripping is > relatively static and not at d-i build time. Here, I have a different conclusion and I personnally think that the advantages of stripping in d-i builds outweight the drawbacks. In understand the the additionnal dependency is not really wanted and I also understand this will add more overhead to the g-i build process. However, keeping the stripping process in our hands has the great advantage that rewriting the stripping script will have to be done only once instead of being reported to each and every font package. The merging font packaging team will probably help smoothing down this process but, at least now, we depend on the numerous font package maintainers and adding stripping on their shoulders will make us even more dependent. So, well, at least until the list of fonts is finally definitive, I would recommend to begin with internal stripping so that we control the process while we're smoothing things up..... When everything is settled down, then we will be able to provide font package maintainers with nice instructions for them to strip the udeb fonts at build time.
Attachment:
signature.asc
Description: Digital signature