~alpine/devel

1

[alpine-devel] abuild vs. makepkg

Details
Message ID
<CAP-r=ZYKewxrcN5fC5gNy6eux+ZvZmyVt4iQh-uixC+m3skFVA@mail.gmail.com>
Sender timestamp
1498502293
DKIM signature
missing
Download raw message
Just got started using alpine; I've been having a good time. However, I'm
curious about the design of abuild: the APKBUILD format is (nearly) a
direct clone of Arch's MAKEPKG, but with small incompatibilities.

What was the reason behind not just using makepkg as it was (missing
functionality?), and would patches aimed at improving compatibility be
worth-while? Reducing the friction porting, say, AUR packages to alpine
seems useful to me.
William Pitcock <nenolod@dereferenced.org>
Details
Message ID
<CA+T2pCFGfzi-hy21nmnR4ZKS2qLdB0m=f+JTaOGcRvADqS-Z8Q@mail.gmail.com>
In-Reply-To
<CAP-r=ZYKewxrcN5fC5gNy6eux+ZvZmyVt4iQh-uixC+m3skFVA@mail.gmail.com> (view parent)
Sender timestamp
1498752724
DKIM signature
missing
Download raw message
Hi,

On Mon, Jun 26, 2017 at 1:38 PM, Dan Anderson
<dan.hillier.anderson@gmail.com> wrote:
> Just got started using alpine; I've been having a good time. However, I'm
> curious about the design of abuild: the APKBUILD format is (nearly) a direct
> clone of Arch's MAKEPKG, but with small incompatibilities.

Alpine's APKBUILD format is indeed derived from PKGBUILD.

> What was the reason behind not just using makepkg as it was (missing
> functionality?),

makepkg generates packages for pacman, not apk, so we would still need
to write our own tool.

If you look at the format itself instead, the reason why is because
makepkg depends on bash, while Alpine's /bin/sh is an Almquist shell,
not bash.  As such, it does not support some of the bash extensions
that makepkg uses.  Put differently, abuild is an adaptation of the
PKGBUILD format used by makepkg that has been adapted to meet Alpine
policy (in terms of our /bin/sh being different and different
packaging objectives).

> and would patches aimed at improving compatibility be
> worth-while?

The patches you propose would not be worth-while, because they would
require us to depend on bash for using abuild.  We don't wish to add
additional dependencies to abuild, and would rather use the official
Alpine /bin/sh.

> Reducing the friction porting, say, AUR packages to alpine
> seems useful to me.

Largely this is going to be an area of friction that is not reduced by
supporting makepkg syntax.  The main areas of friction involve
Alpine's non-use of glibc and systemd.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)