Re: Statically linked library in libdevel packages? (Was: Status of teem package (packaging moved from svn to git))
Hello,
On 28 January 2016 at 14:38, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Andreas Tille writes ("Statically linked library in libdevel packages? (Was: Status of teem package (packaging moved from svn to git))"):
>> I came across this question since policy says (see link above) that
>> static libraries are *usually* provided. I do not question Mattia's
>> arguing but if his opinion might reflect a consensus the wording in
>> policy is IMHO wrong.
>>
>> I stumbled upon the missing static library since d-shlibmove (from
>> d-shlibs package) is requiring this static library (since d-shlibs
>> is implementing library policy). So if there is some consensus to
>> drop the static library I'd file a bug report against d-shlibs.
>
> Static libraries are useful to users who want to build binaries and
> then ship them about without all the library clobber. I don't know
> how much that happens but when it does happen it's probably people who
> are already having some kind of problem.
>
People who build and ship binaries & libraries, do so by building a
docker container and shipping it to docker hub.
And/or any other similar chroot-based deployment solutions are near
enough to that.
(python virtualenvs, go vendorisation, ruby bundler deploy, etc)
because static binaries do not work, e.g. nss does not work, etc.
> Overall I do think the costs of providing the static libraries, even
> where a shared library is also provided, are justifiable.
>
It's an upgrade and security trap. Yeap, upgraded ssl, restarted all
service, but haha not the statically linked ssl one.
Also, on the bring up of new architectures (and/or code bitrot) I have
seen shared libraries no longer detected (e.g. present but cannot be
compiled) and configury falling back to static linking when it was not
intended to.
Imho, if static libraries, are shipped we should be conservative about
them (e.g. do it pretty much for libc only to compile minimal
freestanding bootloaders and that's about it).
Or for example do split them into a separate link path, or separate
package - since it would also require Built-Using stanzas. If one
build-depends on static library package, and doesn't generate
Built-Using something fishy is going on.
Anything leaf, or beyond minimal/core libraries, really has no need
for static libraries. And definitely none of the TLS or crypto
libraries.
--
Regards,
Dimitri.
Reply to: