We've had extensive conversations on this topic elsewhere, and these were pretty much entirely covered in Jamie's comment #27, which does an excellent job describing the various perspectives for the same problems. Thanks for that Jamie.
Just a couple of points that might be useful to add:
[Jamie]
> If we do this with golang-gc (gccgo would follow established update procedures),
> then right away if there is a security update or SRU in golang-foo-dev, we can
> do 'reverse-depends -b golang-foo-dev' to see what needs no change rebuilds.
As an obvious point yet perhaps worth raising, a bug in a library doesn't necessarily mean everything has to be rebuilt.
[Steve]
> My biggest concern here is that making golang-go genuinely supportable in the distro context means
> supporting dynamic linking, and the Go upstream community appears to be quite hostile to the
> principle of dynamic linking.
That sounds like an overstatement. It is true that the Go community appreciates static linkage, and some members have public sayings about how dynamic linkage has its own issues, neither the Go community nor the Go core development team (most important in this case) is not hostile to dynamic linking.
Here is evidence showing progress rather than hostility:
We've had extensive conversations on this topic elsewhere, and these were pretty much entirely covered in Jamie's comment #27, which does an excellent job describing the various perspectives for the same problems. Thanks for that Jamie.
Just a couple of points that might be useful to add:
[Jamie]
> If we do this with golang-gc (gccgo would follow established update procedures),
> then right away if there is a security update or SRU in golang-foo-dev, we can
> do 'reverse-depends -b golang-foo-dev' to see what needs no change rebuilds.
As an obvious point yet perhaps worth raising, a bug in a library doesn't necessarily mean everything has to be rebuilt.
[Steve]
> My biggest concern here is that making golang-go genuinely supportable in the distro context means
> supporting dynamic linking, and the Go upstream community appears to be quite hostile to the
> principle of dynamic linking.
That sounds like an overstatement. It is true that the Go community appreciates static linkage, and some members have public sayings about how dynamic linkage has its own issues, neither the Go community nor the Go core development team (most important in this case) is not hostile to dynamic linking.
Here is evidence showing progress rather than hostility:
https:/ /code.google. com/p/go/ issues/ detail? id=256
http:// code.google. com/p/go/ source/ detail? r=885321ad38732 8c16c6f69fb04b1 2ac69b69b691 code.google. com/p/go/ source/ detail? r=c9e8491bbfcee 7a9c05934f8be07 18bccbf29aec code.google. com/p/go/ source/ detail? r=98034d036d032 138078799756291 72945169c7c8 code.google. com/p/go/ source/ detail? r=1eadf11dd1b7b 19d485768136355 3c2cfd2ad47d
http://
http://
http://