-----BEGIN PGP SIGNED MESSAGE-----
On 25/07/17 01:07, Timo Teras wrote:
> 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
> 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.
How does one bootstrap a new distro? Especially one with a slightly
different triplet (i486-*, powerpc64-*, etc) than Alpine's, not to
mention different configuration options? Should I just build a new
GCC and install it over the current one?
I figured running bootstrap.sh would be the quickest / easiest way to
do that. But maybe I was wrong.
>> 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
> 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
Would there still be a way to choose a different provider later?
>> 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
I know that build-base is probably already a bit larger than it needs
to be... but how many Ada packages are on Alpine to justify the
additional size in build-base? AFAIK no other distro has Ada support
in the base build package. It probably belongs in makedepends.
>>> 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.
+1 for alpine-patches, but alpine-devel works just as well and already
has the subscribers so it is probably fine.
> Thanks! Timo
A. Wilcox (awilfox)
Project Lead, Adélie Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
Received on Tue Jul 25 2017 - 07:30:33 GMT