On 8 July 2016 at 20:03, Potter, Tim (HPE Linux Support)
<timothy.pot...@hpe.com> wrote:
> On 7 Jul 2016, at 12:40 PM, Martín Ferrari <tin...@tincho.org> wrote:
>> On 06/07/16 20:59, Moritz Mühlenhoff wrote:
>>> What's the current status? Is there technical progress compared to what was
>>> discussed in April? The freeze is coming really close and we can't support
>>> the status quo for stretch.
>> The discussion stalled at that point. AFAIK, there is no technical
>> solution for this. The best we could do is to have easier ways to track
>> dependency chains, but that does not change the fact that all golang
>> applications are still statically built, and so would require rebuilds
>> when security bugs are discovered and fixed.
>> I understand this is problematic, but not sure we can do anything about
>> it at this point.
> Hi everyone.  I've done a small amount of research into the buildmode=c-shared
> and the dynlink option and they look good on paper.  Has anyone examined these
> options more seriously?

Well, using them in Ubuntu was the reason Canonical paid me to
implement them, so yes... I'm am currently in the process of starting
to use these features in Ubuntu. My plan, such as it was, was to use
them in Ubuntu through the 16.10 cycle and then propose the changes to
Debian too, assuming they work out OK.

> My guess would be that there might be a bunch of as yet undiscovered
> platform-specific bugs with this,

FWIW, I currently know of no platform specific bugs (if you use 1.7rc1
or the patches on 1.6.2 I have in Ubuntu). But I have been in this
position before :-)

> and it's probably too late at this stage to make
> such a major change to the golang package build process.

I would tend to agree that getting this stood up in time for stretch
isn't a great idea.


Pkg-go-maintainers mailing list

Reply via email to