For discussion of Alpine Linux development and developer support

Re: [alpine-devel] abuild and depends in subpackages

Max Rees
Message ID
Sender timestamp
DKIM signature
Download raw message
On Apr 05 11:06 AM, tcely wrote:
>    On Apr 5, 2019 9:43 AM, Natanael Copa <> wrote:
>      But we need to decide what behavior we want long term: Do we want
>      explicitly (always) unset depends or avoid doing depends="$depends
>      ..."
>      in split functions?
>      I would prefer avoid depends="$depends ..."
>    I would prefer to set origdepends="$depends" before unsetting depends
>    for subpackages, at least temporarily until aports can be fixed.
>    Another way around depends="$depends ..." is to use a variable like
>    depends_dev so that the assignment happens before the split function
>    runs.

I took this last suggestion and ran with it to see if it could be
implemented, since it is tangentially related to my ongoing work with
abuildd. If the properties of a subpackage are set outside of its split
function, then it is much easier to introspect all subpackage properties
without trying to parse shell / formatting (very hard) or running the
split function (not possible unless the package is already being built).
This is something I think Natanael mentioned briefly on #alpine-devel.

A logical extension of this idea is to change the format of $subpackages
from the current format of:

$subpackages="$subpkgname[:$subpkgsplit[:$subpkgarch]] ..."

to something like the following:

$subpackages="$subpkgname $variable[ $value...]

For example, for iproute2:

  $pkgname-bash-completion split bashcomp
  $pkgname-bash-completion arch noarch
  $pkgname-bash-completion depends
  $pkgname-bash-completion pkgdesc bash completions for $pkgname
  $pkgname-bash-completion install_if $pkgname=$pkgver-r$pkgrel bash-completion"

I have what appears to be a working proof-of-concept patch to abuild for
this, albeit not thoroughly tested yet, if anyone is interested in
exploring this further.