Comment 15 for bug 1637546

Revision history for this message
Jeff Lane  (bladernr) wrote :

Per Leann's comment #7 above:

+++
Additional feedback from the Canonical Foundations Team is as follows:

A newer version of memkind appears to require a newer version of jemalloc than what is currently present in the Ubuntu archive (Debian is still at jemalloc 3.6.0 in unstable; so is Ubuntu; memkind requires jemalloc 5). The team did do the work to update the packaging, and went ahead and uploaded it knowing it would fail to build and stall in -proposed. They noted that memkind does bundle jemalloc in its sources, but it is best practice not to use bundled copies, so they did not enable the package to use this. jemalloc 5 is now available in Debian experimental; but this is an soname transition and since we are past feature freeze this is going to miss 17.10. We can sync jemalloc 5 as soon as the archive opens for 18.04 and get this resolved.
+++

Bionic still has jemalloc 3.6.0, it appears the update to version 5 did not occur. I'll ping the Foundations team and see if there is anything we can do but as we are past FF again, I don't know that there is anything that can be done. That said, If you were to snap this instead, you could ensure the snap included any jemalloc version you need or desire. As they indicated, it's preferable to not include experimental or different versions of shared libraries in a deb package, with debs it's entirely possible that could lead to a conflict or errors with other packages looking for those libs. (I'm not saying that will happen in this case, just that it opens the door for that possibility).

But a snap is self contained and you can have any library at any version you need regardless of what other tools are using or calling. Additionally, Intel could create the snap packages and push them to the snap store at your convenience regardless of where we are in the current development cycle, and regardless of any freeze dates.