From: Shiz <hi@shiz.me>
Message-Id: <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_B77D143C-DF16-490B-AA77-65FC7653DB84";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: =?utf-8?Q?Re=3A_=5Balpine-devel=5D_Ad=C3=A9lie_on_Alpine=2C_two_m?=
 =?utf-8?Q?onths_later?=
Date: Mon, 24 Jul 2017 16:53:50 +0200
In-Reply-To: <5975E0C0.1030008@adelielinux.org>
Cc: alpine-dev <alpine-devel@lists.alpinelinux.org>
To: "A. Wilcox" <awilfox@adelielinux.org>
References: <5975E0C0.1030008@adelielinux.org>


--Apple-Mail=_B77D143C-DF16-490B-AA77-65FC7653DB84
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

Thanks for sharing your experiences! I=E2=80=99ll comment on the =
specific cases
below.

> 1.  scripts/bootstrap.sh cannot "fake" cross.  Since Ad=C3=A9lie uses =
a
> slightly different GCC configuration from Alpine, I attempted to run
> bootstrap.sh on x86_64, from my x86_64 system:
>=20
>=20
> ERROR: unsatisfiable constraints:
>   gcc-6.3.0-r4:
>     conflicts: gcc-x86_64-6.3.0-r4[so:libcilkrts.so.5=3D5.0.0]
>     satisfies: world[gcc] g++-6.3.0-r4[gcc=3D6.3.0-r4]
> gcc-gnat-6.3.0-r4[gcc=3D6.3.0-r4] build-base-0.5-r0[gcc]
>   gcc-x86_64-6.3.0-r4:
>     conflicts: gcc-6.3.0-r4[so:libcilkrts.so.5=3D5.0.0]
>     satisfies: world[gcc-x86_64]
>=20
>=20
> Since we have other CPU types that we wish to support, I went ahead
> and simply bootstrapped PowerPC.  This is therefore not a fatal error,
> but one that has caused a lot of time to burn; a lot of packages are
> just not ready for ppc and needed some fixing.  Specifically, GCC and
> OpenSSL needed to be made aware of the PowerPC architecture.

I=E2=80=99m in general not a huge fan of how bootstrapping works at the =
moment,
but I don=E2=80=99t see a direct way to improve it without rewriting it =
entirely
and adding significant new functionality (like proper multiline) to APK.

> 2. The virtual system is pathetic.  One of the very core tenets of
> Ad=C3=A9lie is giving the user power through choice.  That choice is =
almost
> impossible to provide using the current abuild/apk framework.  I keep
> hearing of a Debian-style alternatives system, and supposedly it was
> specified somewhere, but I cannot find the specification nor an
> implementation.  If I could read the specification I would be highly
> motivated to write an implementation.

This is correct and something that has been bothering us for a while.
A while back I wrote up a rough sketch of how such a system would =
function
in APK, which is likely what you are referring to. It can be found here:
https://txt.shiz.me/ZDNkNTY3MD.txt

I have no specific experience with apk-tools=E2=80=99s internals, but =
would be open
to looking into them to see what=E2=80=99s needed, possibly/preferably =
with kaniini
and fabled=E2=80=99s assistance and insights as well.

> Red Hat has `alternatives`, Debian has `update-alternatives`, and
> Gentoo has `eselect`.  The Alpine system desperately needs something
> like this and I would love to contribute to such.
>=20
> Consider a few different use cases:
>=20
> mta: any package that needs `sendmail` has to either hard-depend on
> postfix, or disable mail services.  This is unacceptable in my
> opinion.  Other distros let you select what package you want to
> provide `sendmail`.
>=20
> awk: mawk vs gawk vs busybox awk.  All have benefits and drawbacks and
> the user should be able to choose which provides /usr/bin/awk.
>=20
> shell: /bin/sh as busybox is of course default, but some users may
> want bash or another shell.  I don't see any reason that can't be
> supported.
>=20
> vi: busybox, vim, neovim, elvis, ...  There are almost a dozen
> providers of `vi` in Debian and more than a dozen on Gentoo.  I
> believe Alpine itself packages four of them.

Something I=E2=80=99d like to see is file: dependencies (in the same =
vein
as so:, but for full file paths), but that=E2=80=99d require encoding =
the
entire file listing of a package in its `provides` metadata, which I=E2=80=
=99m
not sure we want due to APKINDEX file size bloat.

> I started to try and make 'v:mta' but I'm very concerned about
> diverging so much from the Alpine aports tree.  Also, apk doesn't
> support an automatic choice for a virtual if the user hasn't already
> installed one (something like replaces_priority but for virtuals would
> be good here imo).  That means that when I *do* manage to get packages
> to depend on v:mta, the user now has to read through an 'unsatisfiable
> constraints' error and pick a package out of the list of providers.

I=E2=80=99m not sure what the best way to approach this would be in the =
system
sketch I laid out above.

> 3. It is very hard to know where to send some things.  For example,
> the GCC APKBUILD does not function properly right now: it does not
> declare a makedepends on gcc-gnat, and the GCC configure process bails
> out when it does not find it because LANG_ADA is true whenever CBUILD
> =3D=3D CHOST =3D=3D CTARGET.  I am not 100% confident in my ability to =
edit
> the APKBUILD for GCC considering how finicky it is, so I would like
> help.  I posted on the IRC channel but I mainly only have the weekends
> to work on Ad=C3=A9lie, and most of the channel is away on weekends.  =
This
> really isn't a distro topic, so it doesn't belong on alpine-devel from
> what I have been able to gather about this list.  The aports list
> seems to be for patches only, from what I have gathered about that
> list.  Maybe this belongs on the bug tracker, but there really isn't a
> bug category for build failures that I could find.

This would be a bug against aports in the bug tracker. Generally most of
us are somewhat busy, especially considering the time of the year.
Pinging specific people can work however =E2=80=94 don=E2=80=99t take =
our lack of response
as lack of interest. :)

> Additionally, changes made to abuild or apk-tools are currently being
> sent via GitHub pull requests.  However, none of us in Ad=C3=A9lie =
really
> want to use GitHub as it is a closed platform.  The aports mailing
> list exists for aports, but where could we send abuild or apk-tools
> changes if we wanted an alternative to GitHub?

These kind of changes should be sent to alpine-devel if you do not wish
to use GitHub.

> 4. We have managed to make a split function 'openrc' that takes
> /etc/init.d and /etc/conf.d directories.  It has install_if=3D"$pkgname
> openrc" so it is transparent when you have OpenRC installed, and
> allows future migrations to a different init system.  I don't know if
> this is of any interest to Alpine.

I=E2=80=99d like to see this, yes. It seems like a good addition in =
light of the
things discussed at FOSDEM with regards to init systems.

> 5. After being annoyed by bugs in the PowerPC build of GNU tar, we
> managed to swap out /usr/bin/tar for bsdtar provided by libarchive in
> abuild.  It needed a patch to output the format apk expects by
> default, but otherwise it seems to work quite well.  This may be of
> interest to those who want to do a GNU-free Alpine spin.

I=E2=80=99m not personally interested in bsdtar as I consider libarchive =
fairly
bloated, but if the patch is backwards-compatible with GNU tar I would
see no issue with including it at all.

> Best,
> --arw

Hope this helped a bit,
- Shiz

--Apple-Mail=_B77D143C-DF16-490B-AA77-65FC7653DB84
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJZdgoEAAoJEI8YjKeZk+kHxRQQAMkPV5IpXdUcgfjez/pH5aRm
6yh7k9U5gAceMIO2jS3502957s1/yDo7cZRmoKNFFdYX56GIFn+977h/LM8xUszK
ZHI2BgphjcwKBmUpdnzGaAfv7jw9Hm1tzTYX8KngdquPSexFuhK7DbLerckTO/RP
8VYDpN41rgHY3OX7YHZO9aVf49gwm3IWVJN1HgVweqV9/+C3E70W+xIQ64bUKbAe
wgd6ME2mjQVEXDTchNKllJV7jnw7clI7DpEuEdscya5mj6h9DlJfwyFWY8+fuf2F
yMZDHPrs1uF2zuFL+HLNjToScj06QK3mXdh3Ei9rDfSZPvjcNpyQnO2L12V2LZUF
48rCumHeexatEB9VoI6svtZ+VamG/t5hGTV+yz+Eh5DauAQmjpyoOnr9LTEnEJm4
UD4MvX4v66gmNlWAVwWt50WJ5Sp0WH4pmki0btYGU8t22g5apQJmM3R8K/eU4SuG
t0DdfcIR81hgbsCOVcIEApgOZ3kdNg/gqKSR6g/Rd537SKdGCZ76mujpuAYOIlrj
xVzaA5Zaw0xAtUaT9bnwOYXeWXVlng+RHWXL6FbfIHmHch/qy2CSh9AsBRqx/s7q
bvINtIHEfA8WEtglB/ySpNZQkDdz+w/uJfSvBRNKBMSgU0e1bwjM4ctymwOobqie
5gCVufDFbLVei1k6MLic
=vK+s
-----END PGP SIGNATURE-----

--Apple-Mail=_B77D143C-DF16-490B-AA77-65FC7653DB84--


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---