Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id D6FEC7811BB for <~alpine/devel@lists.alpinelinux.org>; Tue, 21 Jun 2022 15:49:33 +0000 (UTC) Date: Tue, 21 Jun 2022 15:49:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=panekj.dev; s=protonmail2; t=1655826572; x=1656085772; bh=/mgH12QxUpsfCn/zu89h6p4Cg5B2EX21liT8REqDBnk=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=qYEW8mjYn0V2vrMVi6SMB9uBFqdcvluwcGKMjEDkqzjfkq54sE/ys0uXSU9elEEbb +6l66MiR5keLmGfCDs3kmhB6KClHc18yNgtVQUg9fgmfAn/PHkGBmBanQBolhiWC5S QymFRbtZTFCOrMbo5+lngfNZFC3fjQaPiuVI4b9GwtGzScG0vUHPxpMMz5bIbDfnZU LmpZeddJblbiIZeClJmNMGRS2YG1znKj7ejDwyQWsoIW30ORoUEcB8yjWL00u9gp3o 6VOTipBcN3pa4Las0FB8DD/jQsfC5FHI6ICMfSApVc5JXCLtBIYKVHvEB3KZedykYl sadGEiMpuNTEw== To: Tomas Kolda From: Jakub Panek Cc: ~alpine/devel@lists.alpinelinux.org Reply-To: Jakub Panek Subject: Re: Native Alpine GLibc support (NEW) Message-ID: <2d9mplT0SfCec-0RrOe07ywj3_XWJjggRYxMKVIGYmXVv7RJDr65BgVD-F6Dgxo0u4y5gF3reFXYN5QIVmjZ_hiUY1F6LgkgbCk6Kg9Y5bA=@panekj.dev> In-Reply-To: References: <20220621095653.71773d59@ncopa-desktop.lan> <20220621114559.4d38d98e@ncopa-desktop.lan> Feedback-ID: 39296488:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > =C3=BAt 21. 6. 2022 v 15:05 odes=C3=ADlatel Jakub Panek me@panekj.dev nap= sal: > > > As a person that dabbles with Alpine and is somewhat active in communit= y, > > I agree that glibc doesn't feel right with Alpine. It's not a component > > that you can simply replace in ecosystem as everything has to be rebuil= t > > against it. IMO, libc and package manager are base components which mak= e > > OS distinct so calling it Alpine with glibc would be a disservice as > > Alpine focuses on size, simplicity and security, which for glibc I > > would say neither are a focus. > > So the Alpine can be first distro that supports two libc libraries! ;-) Void Linux and Gentoo as mentioned by alice have done that before so not really "first" :) As for simultaneous multilibc on host it would be a terrible idea as you have to monitor/maintain both libcs at the same time with (IMO) very little benefit. > > I would be happy to contribute towards apk-tools + glibc OS (option b)) > > and it's ports as much as I can but would really recommend for it > > to define itself as separate project from Alpine (e.g. different name). > > I could also provide some compute and storage for it. > > As Natanael said it would increase the resource needs (people) even > more. I think... Changing one library does not need to generate > another distro. Maybe I should share it somehow so you can try it in > chroot or docker to see there is really actually almost no change > which I like most. > > Maybe Jakube we can setup a repository of packages somewhere on your > web server? I can copy it there. Then it is easy to start to play with > that as you have build toolchain ready. Sure, if you can provide a public endpoint (HTTP/SFTP/FTP(S)/RSYNC/other) I can grab and host right it now. If not possible, it will take me some time to set up it for multi-user purpose so you can throw it there yourself :) Whichever the way, you can send me an email directly (as to not clutter mailing list even more) but it would be good to see the modified ports source available publicly so the bootstrap could be verified as well. I'm fine with GitHub, GitLab or wherever it would be hosted with preference for something that could be easily integrated for collaboration and CI/CD. Regards, Jakub P.