Message-ID: <d0c4cab578c513f312390679680eb1cf31690a05.camel@gmail.com>
Subject: RFC on -static subpackages and being more static-linking friendly
From: maxice8 <thinkabit.ukim@gmail.com>
To: ~alpine/devel@lists.alpinelinux.org
Date: Sat, 16 Jan 2021 03:28:08 -0300
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.2 (3.38.2-1.module_f33+10736+4f8d5006) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

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).

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.
2. Avoid using --disable-static or removing the static library with
'rm' and respect the upstream decision to build it by default or not.

Regards
Leo