On 04/10/2016 06:05 PM, Jakub Wilk wrote: > * Milan Kupcevic <mi...@debian.org>, 2016-04-10, 16:51: >>>> We should change policy and packaging tools such that static linking >>>> are not enabled by default and only enabled when there is a good >>>> reason to do so; when requested by users or when there is some other >>> No, we should not. >> >> +1 >> >> A lintian check should suffice. > > Lintian check for what? >
In the context of discussion and Paul's proposal[0][1] lintian check for statically linked binaries in Debian packages should suffice. If the one we've got[2] is deficient then we should look into it and figure out how to fix it. Another way to discourage or eradicate static linking would be a mandate of placement of static library files in a separate development package. This way linking to a static library would require explicit declaration of lib*-static-dev instead of lib*-dev in Build-Depends, for example. Unintentional linking to a static library would not be possible in this case. Removing static option from building tools or completely removing static libraries from development packages would be a step backward. Static linking is unavoidable in building bootloaders, forensic and diagnostic tools that have to run on bare systems or in bare kernel only environments. Moreover, static libraries and static linking option is expected to be available in an universal operating system. They are coming handy for compiling custom binaries intended to run outside of full Debian installation. An example would be a scientific analysis binary running on a cluster where cluster nodes have nothing else but kernel and just a few essential dynamic libraries available. [0] https://lists.debian.org/debian-devel/2016/04/msg00210.html [1] https://wiki.debian.org/StaticLinking [2] https://lintian.debian.org/tags/statically-linked-binary.html
signature.asc
Description: OpenPGP digital signature
