Subject: [alpine-devel] supporting multiple libc's

From: Natanael Copa <[email-masked]>
Date: Fri, 19 Jul 2013 14:35:10 +0200

Hi,

While working on musl/arm we have again bumped into the need for
specifying what libc we use and how to make conditionals in apkbuilds.

Currently we use ALPINE_LIBC in some apkbuilds. We also have some
packages that checks the CHOST. Then we have a libc package that works
as a 'virtual' package providing the correct libc. So on eglibc systems
libc-dev will pull in eglibc-dev as a dependency.

We will introduce a new variable: CLIBC, which should be then name of
the current libc. So if you have a hard dependency for uclibc-dev then
you can use $CLIBC-dev.

This means that ALPINE_LIBC will go away. We will need to fix the
affected apkbuilds. (should be easy enough).

Now, we will need some way to filter out packages based on CLIBC. You
might not want build some package on given libc. How should we specify
that?

Do we want a separate variable for it, like 'arch'?

If so, what should it be called? libcmask?

If not, can we use $options for it?

Some alternives/examples:
#1 whitelist what to build on (like arch)

  libcmask="uclibc eglibc musl"

or
  libcmask="all"

#2 blacklist, and use 'all' if unset

  libcmask="!musl !eglibc"

#3 blacklist via 'options'. assume 'all' if unset.

  options="!musl"

Other ideas?

-nc

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Timo Teras <[email-masked]>
Date: Fri, 19 Jul 2013 15:47:46 +0300

On Fri, 19 Jul 2013 14:35:10 +0200

> #3 blacklist via 'options'. assume 'all' if unset.

If using options, I'd go with options="!libc_musl" or similar.

I think we should aim at trying to have everything regardless of libc.
So the default should be "all". And just blacklist things. Though, it
might that at this stage with musl, we might get quite a bit of those.

I'd perhaps go with #2.

- Timo

---

---

From: Natanael Copa <[email-masked]>
Date: Fri, 19 Jul 2013 16:05:43 +0200

On Fri, 19 Jul 2013 15:47:46 +0300

> might that at this stage with musl, we might get quite a bit of those.

Makes sense.

> I'd perhaps go with #2.

I liked options="!libc_musl"

-nc

---