On Mon, 24 Jul 2017 16:53:50 +0200
Shiz <hi_at_shiz.me> wrote:
> > 1. scripts/bootstrap.sh cannot "fake" cross. Since Adélie uses a
> > slightly different GCC configuration from Alpine, I attempted to run
> > bootstrap.sh on x86_64, from my x86_64 system:
> > ERROR: unsatisfiable constraints:
> > gcc-6.3.0-r4:
> > conflicts: gcc-x86_64-6.3.0-r4[so:libcilkrts.so.5=5.0.0]
> > satisfies: world[gcc] g++-6.3.0-r4[gcc=6.3.0-r4]
> > gcc-gnat-6.3.0-r4[gcc=6.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=5.0.0]
> > satisfies: world[gcc-x86_64]
> > 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’m in general not a huge fan of how bootstrapping works at the
> moment, but I don’t see a direct way to improve it without rewriting
> 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élie 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’s internals, but would
> be open to looking into them to see what’s needed,
> possibly/preferably with kaniini and fabled’s assistance and insights
> 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.
> > Consider a few different use cases:
> > 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`.
> > 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.
> > 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.
> > 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.
Yes. Currently the way it works busybox is a hack. I'd love to get this
> Something I’d like to see is file: dependencies (in the same vein
> as so:, but for full file paths), but that’d require encoding the
> entire file listing of a package in its `provides` metadata, which I’m
> 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=file:/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.
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’m 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 == CHOST == 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élie, 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 — don’t 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.
_at_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élie
> > 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.
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.
Received on Tue Jul 25 2017 - 09:07:51 GMT