For discussion of Alpine Linux development and developer support

6 4

[alpine-devel] A few questions about Alpine

A. Wilcox
Details
Message ID
<593BC99A.5010302@adelielinux.org>
Sender timestamp
1497090458
DKIM signature
missing
Download raw message
-----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
pkg).


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?


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.


4. Is Alpine interested in ports to other architectures supported by
musl including PPC32 and MIPS?


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.


6. Would there be any interest in jointly creating some user-facing
utilities to make the abuild experience a more pleasant one for users?


Thank you for your time.


Best to you and yours,
—arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

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
=blXf
-----END PGP SIGNATURE-----


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
William Pitcock
Details
Message ID
<CA+T2pCEhNMT2x6=L7JZ3nx=3WJZ6ZJiTBJCP7UAv2uGhOkRLpg@mail.gmail.com>
In-Reply-To
<593BC99A.5010302@adelielinux.org> (view parent)
Sender timestamp
1497136678
DKIM signature
missing
Download raw message
Hello,

On Sat, Jun 10, 2017 at 5:27 AM, A. Wilcox <awilfox@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
> pkg).
>
>
> 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?

Yes, absolutely.

> 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
release architectures.
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.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Breno Leitao
Details
Message ID
<307eb90d-54a3-b2a1-5df8-b3d625f4ed39@br.ibm.com>
In-Reply-To
<20170612124719.79f5b172@ncopa-desktop.copa.dup.pw> (view parent)
Sender timestamp
1497269857
DKIM signature
missing
Download raw message
On 06/12/2017 07:47 AM, Natanael Copa wrote:
> On Sat, 10 Jun 2017 05:27:38 -0500
> "A. Wilcox" <awilfox@adelielinux.org> wrote:

<snip>

>> 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.

The current ppc64le machine can run ppc32 virtual machines, and that is how
we do with Debian. The Debian build machines are VMs on top of a ppc64le big box.

Unfortunately we cannot use containers since the kernel use different ABIs
with different byte endianess, that is why we need VMs, with different kernel.



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<20170612124719.79f5b172@ncopa-desktop.copa.dup.pw>
In-Reply-To
<593BC99A.5010302@adelielinux.org> (view parent)
Sender timestamp
1497264439
DKIM signature
missing
Download raw message
On Sat, 10 Jun 2017 05:27:38 -0500
"A. Wilcox" <awilfox@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.

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 :)
 

> 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
> pkg).
> 
> 
> 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.
> 
> 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. 

>  How are build-time dependencies resolved in abuild?  

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.
 
> 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.
 
> 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.
 
> 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.

 
> 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.
> 
> 
> Best to you and yours,
> *arw
> 
> - -- 
> A. Wilcox (awilfox)
> Project Lead, Adélie Linux
> http://adelielinux.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> 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
> =blXf
> -----END PGP SIGNATURE-----
> 
> 
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
> 



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<20170612155808.16b7305a@ncopa-desktop.copa.dup.pw>
In-Reply-To
<307eb90d-54a3-b2a1-5df8-b3d625f4ed39@br.ibm.com> (view parent)
Sender timestamp
1497275888
DKIM signature
missing
Download raw message
On Mon, 12 Jun 2017 09:17:37 -0300
Breno Leitao <brenohl@br.ibm.com> wrote:

> On 06/12/2017 07:47 AM, Natanael Copa wrote:
> > On Sat, 10 Jun 2017 05:27:38 -0500
> > "A. Wilcox" <awilfox@adelielinux.org> wrote:  
> 
> <snip>
> 
> >> 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.  
> 
> The current ppc64le machine can run ppc32 virtual machines, and that is how
> we do with Debian. The Debian build machines are VMs on top of a ppc64le big box.

Very good. We have the needed hardware then for ppc32.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
A. Wilcox
Details
Message ID
<593F11AA.7090203@adelielinux.org>
In-Reply-To
<307eb90d-54a3-b2a1-5df8-b3d625f4ed39@br.ibm.com> (view parent)
Sender timestamp
1497305514
DKIM signature
missing
Download raw message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/06/17 07:17, Breno Leitao wrote:
> 
> The current ppc64le machine can run ppc32 virtual machines, and
> that is how we do with Debian. The Debian build machines are VMs on
> top of a ppc64le big box.
> 
> Unfortunately we cannot use containers since the kernel use
> different ABIs with different byte endianess, that is why we need
> VMs, with different kernel.


One thing to accomplish two things with one VM is to run a ppc64 BE
kernel in the VM, and then use a chroot for ppc32.  This is what we
did and the built packages seem to work fine on real ppc32 hardware
(testing on a few 750s and a few 74x7).


- --arw


- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZPxGoAAoJEMspy1GSK50UycUP/0dCriFLuNh8kCae0s3qpPCD
1enWucGI/et6SzolSi2FKzmBgcI4xhEWiqz21XwnB1HvNIwMDRh9S0Ww1R30/MlR
oLFSihTanUkno1Az+xUQKMNtEO2MglGES9+nxbg13d/ioVxk8njToAvnBZJp86Bt
xi1QVazM7I38xhXav0VgFDAyQlPzzRtBHy52x3MzH/32BlVx3cTdXNr1Z+59J5zR
/hN1Kou1iJpq3xo7PcfRNagMngIP9RA8P+vQuOrzqIlNYRxPUoUSMBGEOB6/jKjE
H4JfSgiRODxX73gJNNGaDbUIbZoC8har+zpqy7mf7GS2BTbqIWtGb6cJRs9hcHpC
HlCNLbNQti+NPJ5csGpfGoEjz09NuSmyCH/AngJiLG3HyDHzK1UKS7xbqUS1q81X
BKlSqscK0vVDaTglF00XDVoqOLOBgw1uFOQvDIDuLS8dBaWV3UDz3x7WSQuZ7E7D
VM8VN329KqTWwirGUgu6yYozvXKX0lh9sGar+oarSRKLeKwl8vBpeEURQg0V6FWz
kmLzW/umW3clSo6OmXUxRI3l2PKrpv4phGlfIsmIkFHO38J64j7AST3x6Wz6hsbq
Tf0NQaaYXK9LyDudg4JAQJ34ISbcKZ/aS1x5ZJ6BiA5aqDADrL1B0aTq//TuNG7i
3mZf0YlyOdr35OEEmSMP
=0fHW
-----END PGP SIGNATURE-----


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
A. Wilcox
Details
Message ID
<593F17C8.7060504@adelielinux.org>
In-Reply-To
<20170612124719.79f5b172@ncopa-desktop.copa.dup.pw> (view parent)
Sender timestamp
1497307080
DKIM signature
missing
Download raw message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/06/17 05:47, Natanael Copa wrote:
> On Sat, 10 Jun 2017 05:27:38 -0500 "A. Wilcox"
> <awilfox@adelielinux.org> wrote:
> 
>> 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.


That is our policy in Adélie as well.  I don't like us to carry
patches and am in contact with various upstreams.

But there are some upstreams that seem to no longer exist (CVS is
one), and some upstreams that are hostile to standards conformance :(
 That is when we start doing package patches.


>> 2. Does the abuild utility support multiple repositories of
>> packages?
> 
> we have "main", "community" and "testing" package repositories.
> 
>> How are build-time dependencies resolved in abuild?
> 
> abuild will call `apk add $makdepends $depends` (more or less), so
> the dependencies needs to be found by apk.


That makes sense.  Much simpler than the overlay situation with ebuild.


>> 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.


Yeah, that makes sense.  So we would just put our repository first in
the /etc/apk/repositories file and then it seems abuild will do the
right thing.  Great to hear, makes life much easier.


>> 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.


I suppose this needs to be in its own thread :)  I have a few
different ideas but I want to continue working with abuild more to get
a better feel for how it works so that my proposal is nice and clean.


>> 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.


Hardware is not an issue for me, my office-turned-build lab has:

3x ppc32
2x mips64
1x mips32
2x sparc64 (not musl ported yet)
2x arm32
2x arm64/aarch64
1x ppc64 (Power4 based)

What kind of requirements do you have for the hardware?  Do I need to
rack some of it at a datacentre for high bandwidth Internet?  Or is an
office-based cable line (~150 mbit) good enough?


>> 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.


Sure, my main concern is being able to run abuild on computers that
don't have ash.  I suppose since most other build systems have a hard
requirement on bash, having a hard requirement on ash isn't unusual.
But I think Alpine can be even better and not have a hard requirement.


>> 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


Replacing a format is pretty hard as I am finding out converting all
our custom ebuilds to APKBUILD.  Hehe.

It is good to know that the door is open to further improvements to
the format.  As I work with it more I will continue to think about
ways to incrementally make it a better format.

One thought that I did have was to have some common things abstracted
into things that could be sourced from the APKBUILD.  Almost like
'inherit' eclasses in Gentoo or '.include' templates in FreeBSD.  (Can
you tell yet which systems I am familiar with?)  It might make things
like Python and Ruby easier to maintain, since you would for instance
just do:


package() {
   . "$templatedir"/python/package
}

check() {
   . "$templatedir"/python/check_pytest
}


But I don't know if that really would save a lot of maintenance
burden, or if it would just shift it to another place.  Will need to
think more and start a new thread for that as well.


Best,
- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZPxe8AAoJEMspy1GSK50UoPwQAJPO4A4tL+JcALkqskTh5Is9
xFiNSatRyEFdEA2BY6Mn6tnex/mgHASeYSeJW9dkRyMq1R6ozO/+Tvcg92x+89ZC
pCckEh4Qq4KW8UcgkoBnZtBIyYjotWRwXe//p4hI3cC8hpPcdRBDGH1031JIngwq
7HhTQgQMggtFvkfrvvf6zYfPAIuN48Wh+NwCBkxByVbZHUXXsr6VD6Xmqkj7gI2U
TCPqxkpRvVW7jkRVihPkKbYGk8Nfq6hNzF/+gNXFdgGnpMGRHYkdV4wxnqDqCu5r
lbu22K/N+D6OerapnQk+kle4F5ONkkpJi9dWtXg2OocPyCKBLu0tOJLfki5TFtV+
BzlLV2FtbaxS0VEoDAE8/7kincfRyX1ouEQN8FUxixpro2eBPSLwzCYeHbgu8vCu
47OagjJyzdVA8xfTnjPN1abn1b2ipiD1Oh4anbRYGTUIhR8I3tyzhrGHk71jc0Wi
bGO7F7oiF3zpGAlOA+TyeK8aQgYj413v2a/vbFrSlKCVVihKjdqBiTn+NHzrSqWE
EnUpISobUBZXttwn20iPx44VSE372LVoYB4iSeq8OGru7/F/xRUHKWMnh+kNdOYO
3h8LxRCVFG7wXiemItkFGCP/BUL9CGaQCi/ZSRduh47k/UMtpCCjzAPCMVwqFP1n
Xo8tifK9N0vMHx+zdvlw
=ICPk
-----END PGP SIGNATURE-----


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---