Date: Mon, 12 Jun 2017 12:47:19 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: "A. Wilcox" <awilfox@adelielinux.org>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] A few questions about Alpine
Message-ID: <20170612124719.79f5b172@ncopa-desktop.copa.dup.pw>
In-Reply-To: <593BC99A.5010302@adelielinux.org>
References: <593BC99A.5010302@adelielinux.org>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, 10 Jun 2017 05:27:38 -0500
"A. Wilcox" <awilfox@adelielinux.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>=20
> Hello Alpine developers,
>=20
> I*m A. Wilcox, the leader of the Ad=E9lie Linux distribution.  We are a
> distribution which, like Alpine, use the musl libc.  We are presently
> using Gentoo*s Portage system for package building, but unfortunately
> we feel that the Gentoo ecosystem is no longer suitable for use.

Versions 1.0 - 1.8 was built with Gentoo's portage. From alpine 1.9 we
switched to abuild.

So yeah, we've been there :)
=20

> Our goals for Ad=E9lie are as follows:
>=20
> - - A lightweight desktop distribution that is user-friendly while still
> remaining a powerful Linux system underneath, built on technologies
> like the musl libc.
>
> - - Support for many CPU architectures including some that Alpine does
> not yet support (we already have PPC32 and experimental MIPS support).
>=20
> - - The ability for users to build some packages the way they want while
> still remaining a binary-first distribution (like FreeBSD*s ports vs
> pkg).
>=20
>=20
> As such, we are considering *rebasing* our distribution on Alpine
> Linux.

I think this makes sense. I am very positive to this.

>  We have a few questions and ideas to think about before we
> would go ahead.
>=20
> 1. If we had either a different set of patches for a package, or our
> patches allowed different features in a package to be built that are
> currently unavailable in Alpine, would Alpine be willing to evaluate
> including them in the Alpine APKBUILD?

Yes.

We try to avoid patching the packages if possible so patches should go
upstream if possible.

But we will evaluate any suggestions for different patches and
different compile time features.

> 2. Does the abuild utility support multiple repositories of packages?

we have "main", "community" and "testing" package repositories.=20

>  How are build-time dependencies resolved in abuild? =20

abuild will call `apk add $makdepends $depends` (more or less), so the
dependencies needs to be found by apk.

> If we had our
> own mesa package, for an example, would abuild be able to build
> against ours when we build packages from the Alpine package tree?  Or
> would we need to maintain a fork of the Alpine tree and maintain our
> changes in the same tree?

Depends a bit if its ABI compatible or not. If its not ABI compatible
then you will have to rebuild all the packages that depends on your
version of mesa and maintain a fork of those.
=20
> 3. Would support for build-time configuration settings (like FreeBSD*s
> ports OPTIONS or Gentoo*s portage USE) be welcomed in abuild?  This
> would allow us (and our users) to build packages how we want while
> still having the defaults remain the same in Alpine upstream.

Yes. This would be welcomed.
=20
> 4. Is Alpine interested in ports to other architectures supported by
> musl including PPC32 and MIPS?

Yes, as long someone steps up and help us do the work, provide the
needed hardware and help maintain the port.
=20
> 5. Would support for alternative shells in abuild be a welcome
> addition (allowing abuild to run in shells including Busybox, bash,
> zsh, etc)?  These changes would only be to more firmly align abuild
> with the POSIX shell standard where applicable.

Yes. We currently use some bashism that is supported in busybox ash
which is handy. For example ${variable/search/replace}. We'd need
figure out which extensions works on which shells and see if we can
allow them or not.

=20
> 6. Would there be any interest in jointly creating some user-facing
> utilities to make the abuild experience a more pleasant one for users?

Yes.

We have talked about replacing APKBUILD format with something else, but
not really been able to come up with anything. The problem is that it
is difficult (if not impossible) to make a total replace, so changes
will need to go incrementally.

The major issue with APKBUILD is that it is not possible to specify the
metadata for subpackages (pkgdesc, depends, arch etc) in global scope,
and regardless of how we define it in shell, it will be clumsy at best.

I also sort of like the template format that void linux uses, or at
least i like parts of it, but I don't like the idea of hard depndency
on bash.

I suppose this is a different discussion, but I think its good that you
know that we are not 100% happy with APKBUILD format, and that we are
open to suggestions and ideas.

-nc

> Thank you for your time.
>=20
>=20
> Best to you and yours,
> *arw
>=20
> - --=20
> A. Wilcox (awilfox)
> Project Lead, Ad=E9lie Linux
> http://adelielinux.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>=20
> iQIcBAEBCAAGBQJZO8mSAAoJEMspy1GSK50UAJgP/RH+LaNmnuCQm/tyeH3YJ67n
> hWU7XBWeSy7NSfkujUTJ6suBA55BQAmkVrrLFuFddi6hLvPLfWFjfOtmwe7GPV7u
> Wn2Sim2dBnANGJeB1W7SqloY84Xdvn9UCBF1ISb3fUzJrADjxWArVPh6y0m+X3IY
> 84iUksE13zRKWlL7jtJ246jnwpf2rrJsMGLACLL4tLh5bM3sF+QUDerVvSo9FAk3
> 9ybo+F9giiGI9qydo+7Xjncz+I5lWgC1JhoTcEoInwiN8AsrCWXWsEAQkZpLjR+z
> qVUNzerZnPsooqH3pNzOpMVuXiGLVGn9+oLUh0l5rI+0s1F5cf1oLYdISscVnfxq
> Mz3EoygBM1jyzGlV4v6i9uwSvfw8sTRFbdT543thXPfQ43DAxHlIFE7xQnIoYNCP
> kvzRWY8csfwwM+rdHMIqIH3fx5+dLasLoQIij6doxTLJVfAQAtqqO3AMRimI82wL
> lb+bPOraWB9y1rvEV5I0V9VeUd+4yrzueroisOuX7vrAAgqMg7jrsPNW+qoLa0hi
> sKy4sJy+tsiFJF8U/7b6qp2w/5m1tZY8sgrYPBfcQi7W0ZSRFug/mqTnJ91LhdDK
> jMxxPe2VF/ofoD/nh2/A02RQ4hAlzOHLTEwIeG7OvABVZxazT3HNc3q0Ls5JIi+P
> xhh30los4Ztq8V3UhNXe
> =3DblXf
> -----END PGP SIGNATURE-----
>=20
>=20
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
>=20



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---