On 07/26/2018 06:03 PM, Jason L Tibbitts III wrote:
"FW" == Florian Weimer <fweimer@xxxxxxxxxx> writes:
FW> I would like to request a change of the Packaging Guidelines,
FW> advising packagers not to interpose malloc.
How strong of a restriction are you looking for? This sort of feels
like something which would at the strongest be a "SHOULD NOT" but maybe
you're looking for an absolute ban.
An absolute ban strikes me as overly broad. However, especially for
shared objects (such as libruby), the implications should be clear: it
is easy to LD_PRELOAD a different malloc, but if the library is linked
against glibc malloc, jemalloc, and then you want to preload tcmalloc
because it helps with your workload, you might run into problems (and if
it's just excessive use of TLS data, most of it unused).
Some maintainers may find it difficult to comply with an absolute ban if
the relevant software doesn't make it easy to change the allocator.
Sure, this is why I mentioned APR pools and Boehm GC—if the APIs a
different, then we obviously can't require porting to system malloc.
If upstream bundles a custom malloc, especially one of the well-known
ones separately packaged in Fedora, some work is required anyway because
the bundled version cannot be installed in a system-wide location, and
RPM provides for it must be suppressed. (See the upstream varnish
packages for an example of an accidental system-wide jemalloc installation.)
Thanks,
Florian
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/SGAT4KVYNGASCWWG2ZFVWPGX7P4JWAA4/
