From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: Re: Wisdom regarding packaging proxysql Date: Wed, 5 Feb 2020 15:23:41 -0500 Message-ID: <20200205202341.GB6380@jasmine.lan> References: <14c5fb54e7130c85981e2240564f151292e3cc27.camel@wine-logistix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:58205) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1izRD9-0004w2-Jl for guix-devel@gnu.org; Wed, 05 Feb 2020 15:23:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1izRD8-0002cB-I7 for guix-devel@gnu.org; Wed, 05 Feb 2020 15:23:47 -0500 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:34119) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1izRD8-0002U7-9U for guix-devel@gnu.org; Wed, 05 Feb 2020 15:23:46 -0500 Content-Disposition: inline In-Reply-To: <14c5fb54e7130c85981e2240564f151292e3cc27.camel@wine-logistix.de> 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: Ellen Papsch Cc: guix-devel@gnu.org On Wed, Feb 05, 2020 at 04:59:01PM +0100, Ellen Papsch wrote: > 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. It's not uncommon to see hard-coded installation prefixes. What else would need to be changed? Is it doable? > 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. Agreed, this is a fork. > 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. I think that's the right idea: use the upstream patches on our jemalloc package.