Subject: RFC on -static subpackages and being more static-linking friendly

From: maxice8 <[email-masked]>
Date: Sat, 16 Jan 2021 03:28:08 -0300

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

---

From: Sören Tempel <[email-masked]>
Date: Sun, 17 Jan 2021 11:45:52 +0100

> Hello

Hi,

> to link will fail to link.

Yep, I ran into this issue quite a few times myself.

> 'rm' and respect the upstream decision to build it by default or not.

Sounds good to me, never really liked the -static split in the first place.

Cheers,
Sören

---

From: Oliver Smith <[email-masked]>
Date: Sun, 17 Jan 2021 22:42:01 +0100

Hi Leo,

> backwards compat is a concern we can make `-dev` provides= and

just to be sure, you are only talking about removing -static subpackages 
for libraries, right?

I want to be sure whether apk-tools-static stays around, as we're using 
this with pmbootstrap (and I'm sure that there are lots of other scripts 
using it to bootstrap alpine systems).

Best,
Oliver

---

From: maxice8 <[email-masked]>
Date: Sun, 17 Jan 2021 18:50:49 -0300

for libraries, right?

yes, the only -static packages that will be gone are those that hold
static libraries (.a).

---

From: Rasmus Thomsen <[email-masked]>
Date: Sun, 17 Jan 2021 22:51:10 +0100

On Sat, 2021-01-16 at 03:28 -0300, maxice8 wrote:
> [...]

+1 on that. We should also trace dependencies for static libs via
`Requires.Private` to make sure we pull in the right pc:* packages.

> 'rm' and respect the upstream decision to build it by default or 

IMHO we should just enable static libs for packages where it's not too
expensive so users don't have to make a Gitlab issue for when they need
static libs too often.

Regards,

Rasmus Thomsen

---

From: maxice8 <[email-masked]>
Date: Sun, 17 Jan 2021 19:02:28 -0300

> `Requires.Private` to make sure we pull in the right pc:* packages.

Good news is that is already done via --print-requires-private, see
abuild.in[1].

> expensive so users don't have to make a Gitlab issue for when they

I have no interest in hunting down whichever packages are expensive or
not to enable static libraries, I prefer to wait for them to make a
GitLab issue or ask for it on IRC (should be friendly enough, everyone
can hop on IRC via a webclient and just ask for it).

That said if someone wants to go through the process of quantifying
`expensive` and enabling on those that do not qualify as `expensive`,
go for it.

At the most **extreme** I would encourage enabling static libraries by
making `--disable-static` and equivalents on other build-systems a
`MINOR` policy violation in atools.

> > Leo

[1]:
https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1586

---

From: Natanael Copa <[email-masked]>
Date: Tue, 19 Jan 2021 21:27:33 +0100

On Sat, 16 Jan 2021 03:28:08 -0300

> 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.

> backwards compat is a concern we can make `-dev` provides= and

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.

> '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.

---

From: Sören Tempel <[email-masked]>
Date: Wed, 20 Jan 2021 20:29:44 +0100

Hi,

> (like qemu user). But we can provide -static when requested and it does

I agree that we don't need to support static linking for our own
packages. However, I think many people rely on us providing static
libraries. I have seen quite a few Docker images using Alpine to build
statically linked versions of OSS software. From the top of my head, the
vis text editor uses Alpine for this purpose [1].

I also have quite a bit of software lying around which I link statically
on Alpine in order to be able to use recent versions of it on ancient
non-Alpine server systems (shells, text editors, …).

> a few exceptions), but can make it available when someone asks for it.

I think we should support static linking of packaged
libraries for the use cases outlined above. Also consider that musl has
some obvious advantage over glibc in regards to static linking, thereby
making Alpine a very decent choice for these use cases.

Greetings,
Sören

[1]: https://github.com/martanne/vis/blob/master/Dockerfile

---

From: maxice8 <[email-masked]>
Date: Tue, 19 Jan 2021 21:15:59 -0300

> (like qemu user). But we can provide -static when requested and it

Yes.

> 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.

> 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.

> > not.

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.

---

From: "Laurent Bercot" <[email-masked]>
Date: Wed, 20 Jan 2021 09:32:19 +0000

>that can't even be used ootb to link statically.

  I find it difficult to believe that my software has to be treated
differently from others. Could you please explain why and how -static
helped you with my software when it did not with other packages?

  I have no opinion on having -static packages or not, as long as
static libraries are made available in -dev if there is no -static.
It is important to allow developers and packagers to use static
libraries if they so choose.

  skarnet.org software uses static libraries by default, because
it's small enough that doing so actually ends up in less RAM usage.
In some cases (like utmps), the .a is actually *smaller* than the
.so, so using a shared library really doesn't make sense from a
resource usage standpoint.
  However, it can be trivially configured to use shared libraries
instead: --disable-allstatic. This flag is present in all my
APKBUILDs, to follow Alpine policy; and a policy change, or an
alternative build, is just a matter of commenting the flag.

  I don't understand the "broken -static package that can't even be
used ootb to link statically" part. Doesn't abuild create actually
functional -static packages?

--
  Laurent