Hi Reinhard, Reinhard Tartler <siret...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/x6r4m2ldgo....@midna.zekjur.net
