On 07/27/2018 06:43 AM, Florian Weimer wrote: > 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). Agreed. >> 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.) Right, if the relevant software doesn't make it easy to change the allocator then that's OK, but what we ship must be made safe to ship. -- Cheers, Carlos. _______________________________________________ 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/UV5XGF3HM3BPCEARZEYKNIG4OGIECXBO/
