Thanks for sharing your experiences! I’ll comment on the specific cases
> 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:
> 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]
> 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.
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.
> 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:
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.
> 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
> 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’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.
> 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’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. :)
> 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.
> 4. We have managed to make a split function 'openrc' that takes
> /etc/init.d and /etc/conf.d directories. It has install_if="$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’d 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’m 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.
Hope this helped a bit,
Received on Mon Jul 24 2017 - 16:53:50 UTC