MIME-Version: 1.0
References: <CAGFcrM=KPg5AZie-ux055SVAZu08EmSJ3s-Q_Map5j5CmGaaKA@mail.gmail.com>
 <20220621095653.71773d59@ncopa-desktop.lan> <CAGFcrMmniJdjO54SHR+Js=5pyuB70A_M0Ge92=pFpxjbBHYC9w@mail.gmail.com>
 <20220621114559.4d38d98e@ncopa-desktop.lan> <CAGFcrMmddidhEknrSUtydvocghN2pm30pUQ8eGsuqEd9eNpLSg@mail.gmail.com>
 <e5703d3f-4953-6797-2a93-324ea72810b9@lamprecht.org>
In-Reply-To: <e5703d3f-4953-6797-2a93-324ea72810b9@lamprecht.org>
From: Tomas Kolda <koldat@gmail.com>
Date: Tue, 21 Jun 2022 14:51:01 +0200
Message-ID: <CAGFcrMmshmDEo=Bh4ooduO0+16RrqF2CKtWkc=AZWtKrry3a9Q@mail.gmail.com>
Subject: Re: Native Alpine GLibc support (NEW)
To: Thomas Lamprecht <thomas@lamprecht.org>
Cc: ~alpine/devel@lists.alpinelinux.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=C3=BAt 21. 6. 2022 v 14:00 odes=C3=ADlatel Thomas Lamprecht
<thomas@lamprecht.org> napsal:
>
> Basically all of above is also true for Arch Linux which supports glibc, =
so
> why not use that? I'm using it in a hosted VM for some personal important
> services since over six years, without any issue whatsoever and quite goo=
d
> experience - packaging is also simple and straight forward, so not hard t=
o
> re-package one's application for Arch Linux.
>
Maybe ... :)
>
> FWIW, if your working at a company that would profit from such a thing wh=
y
> not try to implement glibc integration and build CI yourself, you wouldn'=
t
> even need to cover the whole archive available in Alpine Linux, just a ja=
va
> build and the external library dependencies of your app. Basically doing =
the
> approach of Nico's (a) proposal yourself.
>
Yes that is what we have and what we use already. We are building it
based on incoming changes. I am just merging it with my changes. Any
difference to community is not good so I am just trying to have it
official. Maybe more people needs something like this. So it is not
just "idea". It is working project.
>
> That would serve as good proof of concept and give a much better idea abo=
ut
> practicability and maintenance effort required, it also could proof that
> this change alone was really responsible for the performance hit your app
> took and you wouldn't need to wait for any such hypothetical change being
> released in upstream Alpine Linux.
>
- This introduce some changes in some of the ports (mostly only
disable MUSL tweaks) - so far like 5% of packages require change
- This introduce one more build as it behaves like new architecture
- I agree that having build of all is hard to estimate. But after
initial bootstrap (nightmare at least for me) I was able to "fix" that
300 packages in two days.