Comment 6 for bug 612363

Benjamin, I believe there are three ways to proceed - I'd appreciate your input on choosing:

1) Make binutils-avr work with maverick's binutils (which comes from experimental). I don't want to do this since avr is a unique architecture, and the avr community has put in much work writing and maintaining patches to make the arch work. The patches right now don't apply 100%, and I don't know of any other bugs that have sprung up during development. The branch that is most complete is the the 2.20.1 version, which is the sid version. I can try to make the 2.20.51+svnsnapshots work, but am more confident in the 2.20.1 version and patches.

2) We add a new package, binutils-source2.20.1, which is a sync with the unstable binutils. We then make binutils-avr depend on the new package. That might be confusing to users (having two binutils-source), so we can name it something else (binutils-source-avr2.20.1) and remove it when the experimental/unstable split ends in debian's binutils.

3) I can include the binutils source for 2.20.1 inside the binutils-avr package (it's debian native), and not depend on on any binutils-source.

or the default of not doing anything and living with binutils-avr that ftbfs in maverick.

Thanks,
Scott