Re: Wisdom regarding packaging proxysql

[Leo Famulari]

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.