# embedded libmagic (from file) - Thread: https://externals.io/message/51735 - Original archive: https://news-web.php.net/php.internals/51735 - Started by ondrej@sury.org on 2011-03-21T17:00:44+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #51735 — ondrej@sury.org — 2011-03-21T17:00:44+00:00 URL: https://externals.io/message/51735#51735 Hi, [I have searched the list and no relevant answer came up, only one unanswered question (*)] I would like to ask whether there is a strong reason to have customized libmagic in the source tree as the only option. I saw the discussion that you want to have embedded magic database, but still I would like to have an option to use system libmagic if available. This is similar to libgd, etc. I know your reasoning and I respect that decision, but still the needs of distributions (and need for longterm security support) raises this as an issue which would be better solved by using system-wide libmagic library. I could hack fileinfo module myself, but I feel that this effort would be better coordinated with upstream if possible. What are your thoughts? Ondrej * - http://marc.info/?l=php-internals&m=117198246420629&w=2 -- Ondřej Surý Hi, > > [I have searched the list and no relevant answer came up, only one > unanswered question (*)] > > I would like to ask whether there is a strong reason to have > customized libmagic in the source tree as the only option. I saw the > discussion that you want to have embedded magic database, but still I > would like to have an option to use system libmagic if available. > > This is similar to libgd, etc. No, it is definitively not the same than libgd. Libgd is now being synced and the core features were the same. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #51737 — Scott MacVicar — 2011-03-21T20:13:17+00:00 URL: https://externals.io/message/51735#51737 · In reply to: #51736 I have a diff sitting that I did yesterday that upgrades us to the latest libmagic, it supports the new magic file format and updates that bundle. But that's all. I'm also against allowing the non-php version. Yes it's a fork but unfortunately it's for the best. - Scott > hi, > > Many incompatibilities and features are not available upstream. The > more we work on it the more differences we have. I have to strongly > (really strongly) discourage any kind of hacks to allow external > libmagic usage. That will only limit the features available to the PHP > users, like stream support for example. > > Cheers, > > > > […] > > No, it is definitively not the same than libgd. Libgd is now being > synced and the core features were the same. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #51738 — Raphael Geissert — 2011-03-22T05:06:28+00:00 URL: https://externals.io/message/51735#51738 · In reply to: #51737 Scott MacVicar wrote: > I have a diff sitting that I did yesterday that upgrades us to the > latest libmagic, it supports the new magic file format and updates > that bundle. But that's all. > > I'm also against allowing the non-php version. Yes it's a fork but > unfortunately it's for the best. Last time I checked there were some general bug fixes (e.g. fixing type casting) that were not in upstream's version. Were they forwarded for 5.05? (I haven't personally checked) It's easy to understand the wish of hacking libmagic to provide some more features, but it would be great to keep the divergence to the strict minimum. Cheers, -- Raphael Geissert --- ## #51739 — sean finney — 2011-03-22T08:10:58+00:00 URL: https://externals.io/message/51735#51739 · In reply to: #51738 > It's easy to understand the wish of hacking libmagic to provide some more > features, but it would be great to keep the divergence to the strict > minimum. And ideally we could find some kind of technical solution/compromise that would keep all parties satisfied. I know this is a touchy subject, but embedded code copies are a pretty big issue for us and not allowing them plays a part in what keeps the QA in Debian so well respected. I haven't looked very closely at this particular problem, but as a last resort (assuming we can't find something one-size-fits-all), we can always add support in the debian source package, so that users who want any missing functionality can easily get it by recompiling with some arbitrary option (like what we're already doing with PHP5_COMPAT for keeping ABI compatibility). sean --- ## #51740 — Pierre Joye — 2011-03-22T13:05:01+00:00 URL: https://externals.io/message/51735#51740 · In reply to: #51737 why don't you publish it then? So we can review it and maybe apply it already. > I have a diff sitting that I did yesterday that upgrades us to the > latest libmagic, it supports the new magic file format and updates > that bundle. But that's all. > > I'm also against allowing the non-php version. Yes it's a fork but > unfortunately it's for the best. > > - Scott > > > > […] > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org