Date: Tue, 19 Jan 2021 21:27:33 +0100
From: Natanael Copa <ncopa@alpinelinux.org>
To: maxice8 <thinkabit.ukim@gmail.com>
Cc: ~alpine/devel@lists.alpinelinux.org
Subject: Re: RFC on -static subpackages and being more static-linking
 friendly
Message-ID: <20210119212733.11bcc69b@ncopa-desktop.lan>
In-Reply-To: <d0c4cab578c513f312390679680eb1cf31690a05.camel@gmail.com>
References: <d0c4cab578c513f312390679680eb1cf31690a05.camel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sat, 16 Jan 2021 03:28:08 -0300
maxice8 <thinkabit.ukim@gmail.com> wrote:

> Hello
> 
> Our current -static packages were rushed in without much testing and
> prototyping and are suboptimal.
> 
> First, abuild has no automatic dependency tracking like -dev has by
> tracking the 'Requires:' field from pkg-config and handling solinks.
> 
> This means that every -static subpackage which requires another package
> to link will fail to link.
> 
> As an example: I faced it with libgit2 while working on 'agl',
> installing libgit2-static wasn't enough I had to install openssl-libs-
> static, http-parser-static, etc separately while they should be
> installed all at once when I requested libgit2-static.
> 
> Considering Alpine Linux uses a very static-linking friendly musl and
> statically linking is actually feasible and done in some places (apk-
> tools-static, busybox-static) I think it is important that doing it
> actually works seamlessly for the user (and us).

My thinking is that we don't really support static linking for our own
packages. We should always use dynamic linking, with a few exceptions.
(like qemu user). But we can provide -static when requested and it does
not cost us much.

> Second, the size reduction is minimal for the -dev package, and -dev
> packages aren't really expected to be small.
>
> Third, the benefit of avoiding accidental linking has materialized (at
> least for me) only once when upgrading the skarnet suite of tools.
> 
> While it is a nice benefit it doesn't happen often enough or is not
> apparent enough when maintaing packages in aports.
> 
> My proposals are:
> 
> 1. Remove -static subpackages and move the static library to -dev, if
> backwards compat is a concern we can make `-dev` provides= and
> replaces= `-static` too.

The main reason we want have a separate -static package is to avoid
accidentally link to static library. By having it in separate package
you need to explicitly install it, or you will get dynamic linking.

Second reason is that we normally don't need the static libraries so
its just bloat. In most cases it does not matter install 3MB extra, but
IMHO its just waste. Some of the static packages do have significant
size. llvm10-static for example, is 189MB.

> 2. Avoid using --disable-static or removing the static library with
> 'rm' and respect the upstream decision to build it by default or not.

I think we should use --disable-static as the default, and enable
static on request. We shouldn't use the static library ourselves (with
a few exceptions), but can make it available when someone asks for it.


> 
> Regards
> Leo
>