Re: [alpine-devel] A few questions about Alpine
On Sat, Jun 10, 2017 at 5:27 AM, A. Wilcox <awilfox_at_adelielinux.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> Hello Alpine developers,
> I’m A. Wilcox, the leader of the Adélie 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.
> Our goals for Adélie are as follows:
> - - 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).
> - - The ability for users to build some packages the way they want while
> still remaining a binary-first distribution (like FreeBSD’s ports vs
> As such, we are considering “rebasing” our distribution on Alpine
> Linux. We have a few questions and ideas to think about before we
> would go ahead.
> 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?
> 2. Does the abuild utility support multiple repositories of packages?
> How are build-time dependencies resolved in abuild? 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?
abuild has no repository awareness at all. It just looks at APKBUILD files.
We use aports-build to run the buildservers which generate the actual repos.
> 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 is a planned feature already. We just haven't gotten around
to making a spec for how it will look in an APKBUILD.
> 4. Is Alpine interested in ports to other architectures supported by
> musl including PPC32 and MIPS?
Yes. We would like to have all architectures supported by musl as
I am planning on doing MIPS64 in the 3.7 release series.
> 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.
This is probably OK, as long as it retains compatibility with Alpine's /bin/sh.
> 6. Would there be any interest in jointly creating some user-facing
> utilities to make the abuild experience a more pleasant one for users?
We are open to proposals to do so, as the point was to enable such
things in the first place.
Received on Sat Jun 10 2017 - 18:17:58 GMT