Message-ID: <9d3541ec2a2890703a1cfdbda9d4d50136308699.camel@gmail.com>
Subject: Re: RFC on -static subpackages and being more static-linking
 friendly
From: maxice8 <thinkabit.ukim@gmail.com>
To: Natanael Copa <ncopa@alpinelinux.org>
Cc: ~alpine/devel@lists.alpinelinux.org
Date: Tue, 19 Jan 2021 21:15:59 -0300
In-Reply-To: <20210119212733.11bcc69b@ncopa-desktop.lan>
References: <d0c4cab578c513f312390679680eb1cf31690a05.camel@gmail.com>
	 <20210119212733.11bcc69b@ncopa-desktop.lan>
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

On Tue, 2021-01-19 at 21:27 +0100, Natanael Copa wrote:
> 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.
> 

Yes.

> > 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.
> 

The split has helped me only once, while dealing with skarnet software
suite, I don't think it is worth it to have a broken -static package
that can't even be used ootb to link statically.

> 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.
> 

It is bloat part of the -dev subpackage which I don't consider as
important as avoiding bloat in the main packages (which we expect users
to install in the containers permanently) most users install -dev and
then remove it after compiling the final binary for their docker
containers.

> > 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.
> 

I prefer letting upstream decide if they want or not, if they(upstream)
compile a static library then don't mess with it, if they don't then
enable **only** if someone requires it.

> 
> > 
> > Regards
> > Leo
> > 
>