Re: [RFC] Go (golang) packaging
Hi Reinhard,
Reinhard Tartler <siretart@gmail.com> writes:
> Consider this from the application perspective: Say an application
> links against a library libfoo.a. At some point, libfoo decides to
> include compression support, and requires functionality from libz. No
> problem for the library package maintainer; he just adds a
> build-dependency on libz-dev, and uploads the package. At some point
> the security team needs to update the application and finds the
> package to FTBFS because libz is missing. The solution, of course, is
> now to extend the build-dependencies of the application package.
> However, this is not obvious and in any case more effort than a
> binNMU.
Thanks for your example. It occurs to me that the following way deals
with the problem:
The hypothetical “foo” package is packaged as “golang-foo-dev”.
The hypothetical application is packaged as “barapp”, which
Build-Depends on “golang-foo-dev”.
When golang-foo-dev starts depending on additional libraries, say
“golang-zlib-dev”, it not only adds that library to its Build-Depends,
but also to its Depends. This is okay because you cannot use
“golang-foo-dev” without having “golang-zlib-dev” installed (as you
explained), and normal users don’t get an unnecessary dependency because
“barapp” doesn’t Depend (only Build-Depends) on either of these
libraries anyway.
I hope my explanation was clear, the tl;dr is “static golang libraries
should mirror Build-Depends into Depends”. What do you think?
--
Best regards,
Michael
Reply to: