Re: About the media types text/x-php and text/x-php-source
On Fri, Aug 24, 2012 at 6:36 PM, Thomas Goirand <zigo@debian.org> wrote:
> On 08/24/2012 10:04 PM, Charles Plessy wrote:
>> Dear all,
>>
>> I note that neither Fedora nor Ubuntu systems associate the text/x-php
>> and text/x-php-source media types to .php files by default.
Fedora uses IANA as an authoritative source and our mime-types are way behind:
$ diff -uw mime.types.debian mime.types.fedora | diffstat
mime.types.fedora | 1693 +++++++++++++++++++++++++++++++++++++-----------------
1 file changed, 1187 insertions(+), 506 deletions(-)
Eg. there are 1693 differences between Fedora and Debian mime.types file.
And something from other side, there is no text/x-python in Fedore
mime.types files...
Ubuntu pull the packages from Debian unstable:
* Merge from Debian unstable. Remaining changes:
- Add "cautious-launcher" for handling execution of files that are
outside /usr and /opt (LP: #506702).
- Fix typo in cautious-launcher dialog.
That really proves nothing.
BTW Gentoo has even different mime.types file:
mime.types | 1298 +++++++++++++++++++++++++++++++++++++++++++------------------
1 file changed, 929 insertions(+), 369 deletions(-)
Also I don't think you have a definitive say in what associations are
needed in mime-support package. It's up to individual "users" of
mime-support package (read individual packages) to define what they
need for correct functionality. I think of mime-support like kind of
"support" package.
>> Today, a rogue NMU on the mime-support package added these associations in
>> Debian.
There was nothing rogue about NMU, which fixed RC bug (well, three)
with major impact on PHP users which were opened for more than a half
year.
>> I intend to revert that change
I suggest you explain first how you intend to fix the RC bugs in
mime-support package if you are going to revert the change which fix
confirmed RC bugs.
I think the release team should have a say in that.
Also please write technical reasons why text/x-php (or
application/x-php whatever) is wrong. Unless you can come up with
technical reasons (f.e. it breaks something) please leave it in the
place, as it fixes critical bug (a regression) in processing PHP files
inside apache (and maybe also in other places).
>> unless there there is a solid explanation
It's explained in #670945:
> If mod_negotiation requires some mime-type for .php to work, then the
> obvious solution would be to add a non-magic type, for example
> "application/x-php".
Manifestations of this bug are also described in #661240, #664691.
This is a major regression from squeeze.
It's always good to stick to technical arguments and I say that this
fixes mod_negotiation processing inside an Apache (and possibly other
places), and it fixes major RC bug(s).
> This might have something to do with #674089.
Only vaguelly, in fact it's a separate issue with same cause.
>> on why we should single out ourselves from the major distributions in our field.
We already single out ourselves (Ubuntu really doesn't count).
> I believe Ondrej (hereby Cc:) must know.
Thanks, Tomas.
> Please do not use:
> text/x-php
> but replace it with:
> application/x-php
>
> The use of text/ for interpreted languages (scripts) is discouraged
> already by IETF and things like javascript/ecmascript are already
> migrated to application/*, the legacy text/* definitions being
> deprecated.
Chris, this is surely not critical severity. I have cloned your bug
report, assigned it a right severity and retitled it to "mime-support:
use of text/ for interpreted languages is discouraged" since we have
several interpreted languages in our mime.types
text/x-perl
text/x-python
text/x-tcl
text/x-sh
text/x-java
text/x-haskell
[...]
Fedora has already moved perl to application/x-perl, so basically I
agree with you, but I would suggest we keep all the languages in sync
and move them post release. I would be quite a huge change to mingle
with existing MIME-Types in the freeze.
We might start by syncing MIME-Types with IANA since we are missing
too many new MIME-Type definitions, but again I think it's already too
late in the release cycle to think about that, but again I do not
speak for release team.
O.
--
Ondřej Surý <ondrej@sury.org>
Reply to: