Subject: Re: [alpine-devel] A few questions about Alpine
To: alpine-devel@lists.alpinelinux.org
References: <593BC99A.5010302@adelielinux.org>
 <20170612124719.79f5b172@ncopa-desktop.copa.dup.pw>
From: "A. Wilcox" <awilfox@adelielinux.org>
Organization: =?UTF-8?Q?Ad=c3=a9lie_Linux?=
Message-ID: <593F17C8.7060504@adelielinux.org>
Date: Mon, 12 Jun 2017 17:38:00 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
Precedence: list
MIME-Version: 1.0
In-Reply-To: <20170612124719.79f5b172@ncopa-desktop.copa.dup.pw>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable

-----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:
>=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?
>=20
> Yes.
>=20
> We try to avoid patching the packages if possible so patches should
> go upstream if possible.
>=20
> But we will evaluate any suggestions for different patches and=20
> different compile time features.


That is our policy in Ad=E9lie 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?
>=20
> 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.


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?
>=20
> 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.
>=20
> 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?
>=20
> Yes, as long someone steps up and help us do the work, provide the=20
> 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=20
>> 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.
>=20
> 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?
>=20
> Yes.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> -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

- --=20
A. Wilcox (awilfox)
Project Lead, Ad=E9lie 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
=3DICPk
-----END PGP SIGNATURE-----


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---