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.