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ý <ondrej@sury.org
- http://marc.info/?l=php-internals&m=117198246420629&w=2
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,
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
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,
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
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
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
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
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,
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
--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org