From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ellen Papsch Subject: Wisdom regarding packaging proxysql Date: Wed, 05 Feb 2020 16:59:01 +0100 Message-ID: <14c5fb54e7130c85981e2240564f151292e3cc27.camel@wine-logistix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:44092) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izN52-0003d0-S8 for guix-devel@gnu.org; Wed, 05 Feb 2020 10:59:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1izN50-0003eF-ON for guix-devel@gnu.org; Wed, 05 Feb 2020 10:59:07 -0500 Received: from dedi718.your-server.de ([78.46.1.118]:52482) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1izN50-0003Ms-Fk for guix-devel@gnu.org; Wed, 05 Feb 2020 10:59:06 -0500 Received: from sslproxy03.your-server.de ([88.198.220.132]) by dedi718.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1izN4v-0002lx-9w for guix-devel@gnu.org; Wed, 05 Feb 2020 16:59:01 +0100 Received: from [80.146.188.122] (helo=pluto.fritz.box) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1izN4v-000STG-7H for guix-devel@gnu.org; Wed, 05 Feb 2020 16:59:01 +0100 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org Hello Guix, I'm currently packaging proxysql, of course with the goal of getting it into Guix upstream as well. There are two hurdles, which I thought I should discuss here. The first is the rather unflexible Makefile based build system. It would require some patching on Guix side. For example, the install phase installs into a hard coded prefix (/usr). I played with the thought of adding a meson build, but it would require forking and I don't want to force something on upstream. The second hurdle is the extensive bundling of dependencies, all in all 16 libraries. I looked closely which libraries are modified in any way. Luckily, 14 libraries are not modified and can be added directly as inputs, of which 3 will need to be packaged (clickhouse-cpp, libhttpserver, libinjection). Remaining ones are jemalloc and mariadb- connector-c. mariadb-connector-c is patched quite extensively, in ways that add specific proxysql behavior documented in their wiki and relied upon by users. For example, ma_password_c.patch changes the hashing behavior of passwords, allowing users to specify passwords in a custom hash presentation. I would keep this library bundled, because it constitutes a fork, given the modifications. The situation with jemalloc is better, only two small patches are applied. issue823.patch solves a performance issue observed in a benchmark. Authors of jemalloc declined the patch, noting that it optimizes something they do not really want to support[0]. issue2358.patch fixes a bug which is also fixed upstream and slated for the next release[1]. A minor proxysql feature is affected[2]. I'm inclined to use the jemalloc from Guix, although create a customized version just for proxysql with the two patches applied. If I don't apply the first one, the main proxysql auhtor will personally haunt me (he seems to value performance above all). The second patch unbreaks an application feature. Please let me in on your wisdom ;-) Best regards Ellen [0] https://github.com/jemalloc/jemalloc/pull/523 [1] https://github.com/jemalloc/jemalloc/issues/1605 [2] https://github.com/sysown/proxysql/issues/2358