Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Date: Tue, 25 Jul 2017 09:07:51 +0300
From: Timo Teras <timo.teras@iki.fi>
To: Shiz <hi@shiz.me>
Cc: "A. Wilcox" <awilfox@adelielinux.org>, alpine-dev
 <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] =?UTF-8?B?QWTDqWxpZQ==?= on Alpine, two months
 later
Message-ID: <20170725090742.61793ff2@vostro>
In-Reply-To: <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me>
References: <5975E0C0.1030008@adelielinux.org>
	<57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, 24 Jul 2017 16:53:50 +0200
Shiz <hi@shiz.me> wrote:

> > 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
> > 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.

The above error is mostly due to GCC having strict versioned
dependencies for the exact pkgversion + pkgrel. And probably the
gcc APKBUILD you tried to use to bootstrap did not match the gcc
installed on your system. I am not entirely sure how the dependencies
should be fixed.

Additionally the crossbuild mechanism is triggered by build arch being
different from host arch. So bootstrapping same architecture is not so
trivial. This is also how it works on gcc, though it's using the arch
triplets. As such the bootstrap script is currently really intended for
bootstrapping new architectures only.

> 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 rewrit=
ing
> it entirely and adding significant new functionality (like proper
> multiline) to APK.

Could you elaborate this a bit? We actually now properly cross-build
and package .apk package at each step. While it's not polished,
it does actually technically the correct thing in most cases.

> > 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. =20
>=20
> 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
>=20
> I have no specific experience with apk-tools=E2=80=99s internals, but wou=
ld
> be open to looking into them to see what=E2=80=99s needed,
> possibly/preferably with kaniini and fabled=E2=80=99s assistance and insi=
ghts
> as well.

Yes, this has been discussed couple of times. I've been designing apk
v3 with different implementation for resolving file conflicts. The
basic idea being as described in Shiz's note (though this is the first
time I see it). The plan was to resolve conflicts first based on the
'replaces priority' but have some sort of manual override.

> > 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.=20

Yes. Currently the way it works busybox is a hack. I'd love to get this
fixed too.

> 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.

We have some intent to add full DB of files, as separate index files.
I'd rather not depend file directly. But nothing prevents adding
"provides=3Dfile:/bin/foo" from multiple packages and have packages
depend on it.

In fact this is how the automatic dso dependencies work; they scan for
the .so files, and create provides for it, and depends on them.

> > 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. =20

Correct. The automatic choice is done only if the provided dependency
is versioned, but that also automatically conflicts with other
providers of the same dependency.

It was intentional design choice to not do automatic choice for the
versionless provided names. Replaces priority or similar work here. But
I would like to give a bit more thought to this.

> I=E2=80=99m not sure what the best way to approach this would be in the s=
ystem
> sketch I laid out above.
>=20
> > 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 i=
n 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. =20
>=20
> 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. :)

Agreed. Alpine-devel mailing list like you did now is also good :)

Toolchain assumes to have toolchain on builders. gcc-gnat is somehow
nasty, it should be in build-base *or* in makedepends explicitly. But
IIRC, the build scripts had some limitations on this originally.
Perhaps this is fixed now.

@ncopa Could we just add gcc-gnat to gcc's makedepends, or build-base?

> > 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? =20
>=20
> These kind of changes should be sent to alpine-devel if you do not
> wish to use GitHub.

We've picked up patches to abuild and apk-tools from alpine-devel and
alpine-aports mailing lists. Perhaps we should have alpine-patches or
similar for non-aports patches.

Thanks!
Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---