Arch Linux

This is a problem as we have AUR packages for nginx which conflict with this. +1 that only nginx package should install into /etc/nginx.

Here is a patch for mailcap which removes the nginx-related files (assuming this is the desired route).

And here is a patch for nginx which keeps the upstream mime.types and removes the dependency on mailcap (again, assuming this is the desired solution).

This is still causing problems our custom deployments of nginx.

AUR packages are not a concern.

Thanks for your input.

I think it's unreasonable to completely disregard AUR packages, because your also really ignoring people who want to do source installations too.

Nginx provides it's own mime.types file (https://github.com/nginx/nginx/tree/master/conf), but the PKGBUILD file removes it: `rm "$pkgdir"/etc/nginx/mime.types # in mailcap` from nginx-mainline.

Arch linux's guiding principles (https://wiki.archlinux.org/index.php/Arch_Linux):

Simplicity: Arch Linux defines simplicity as without unnecessary additions or modifications. It ships software as released by the original developers (upstream) with minimal distribution-specific (downstream) changes: patches not accepted by upstream are avoided, and Arch's downstream patches consist almost entirely of backported bug fixes that are obsoleted by the project's next release.

I think that this is an unnecessary modification of the nginx package.

It also means that nginx unnecessarily depends on mailcap, and that mailcap installs configuration files which are by default unnecessary unless the user also installs nginx. For a typical user, it might be confusing that /etc/nginx exists even without nginx installed.

I think a better solution would be to use the nginx mime.types files as it was, and then provide the ability for users to easily install the mailcap mime.types if needed, e.g. using the supplied shell script from mailcap, or perhaps installing that file but in an alternative location, e.g. /etc/mailcap/nginx-mime.types and allowing users to specify the nginx configuration to use this alternative location.

If AUR packages conflict with the repos, it is as a general rule of thumb their responsibility to adapt. Source installations should not clash in the package manager, at worst you will have files which don't match the packaged ones.


The fact that nginx decided to maintain their own vendored and heavily inferior mime.types *configuration file* is not proof positive that providing our own is diverging from upstream. mailcap is our canonical source for mime.types and it makes sense to treat it as such. The Arch Way isn't very applicable here.

A single 98KB dependency that serves a useful purpose is, well, not unnecessary, and also not burdensome, from a nginx perspective.

From a random users perspective, I guess we could in theory symlink it in the nginx package to a file provided by mailcap which could not go in etc/mailcap/ because that is already a file, but I guess we could find some other location to spare peoples' confusion. More importantly, that symlink would not clash with source or AUR installations any more than the rest of nginx would.

Also I think thematically the apache package should undergo the same change as nginx, and rely on the single authoritative mime.types defined by the user's system.

Thanks for your input.

> If AUR packages conflict with the repos, it is as a general rule of thumb their responsibility to adapt.

I absolutely agree with this.

> Source installations should not clash in the package manager, at worst you will have files which don't match the packaged ones.

Yep, that makes sense. Unfortunately right now I don't feel that this is the case. If I install mailcap, it will install /etc/nginx/mime.types and a source installation of nginx will conflict with this. (e.g. if you were to install nginx from source before installing mailcap, pacman would barf).

> The fact that nginx decided to maintain their own vendored and heavily inferior mime.types *configuration file* is not proof positive that providing our own is diverging from upstream. mailcap is our canonical source for mime.types and it makes sense to treat it as such. The Arch Way isn't very applicable here.

Fair enough. I understand where you are coming from. I guess nginx was faced with supporting a wide range of systems and couldn't depend on /etc/mime.types existing, or perhaps that people would want to only have a limited set of mime.types available when serving files via a web server.

I do understand the value of having a central source of truth. However, at least form one point of view, this diverges from the arch way since other packages now need to be modified to depend on it. The traditional solution to this has been to submit upstream patches, e.g. to nginx and apache, to allow for them to support, e.g. /etc/mime.types as it currently stands, without modification of either how mime.types works or the upstream packages by PKGBUILD.

> A single 98KB dependency that serves a useful purpose is, well, not unnecessary, and also not burdensome, from a nginx perspective.

Nginx worked perfectly fine before depending on mailcap.

> From a random users perspective, I guess we could in theory symlink it in the nginx package to a file provided by mailcap which could not go in etc/mailcap/ because that is already a file, but I guess we could find some other location to spare peoples' confusion. More importantly, that symlink would not clash with source or AUR installations any more than the rest of nginx would.

I think this would be a good compromise. I think it would make sense to have a master mime.types file, and it should be easy for the user to generate the specific configuration files for apps that need different formats. Alternatively, perhaps someone should work on an upstream patch to nginx so that it IS compatible with mime.types file as it currently stands. There are a few different options, but I think it would. make the most sense to minimise the breakage of existing AUR package when a good alternative exists, e.g.

- Install app specific files to /etc/mailcap/nginx-mime.types (or perhaps something more descriptive like `/etc/mime/$app.types`, -> `/etc/mime/nginx.types`).
- Have a master file, e.g. `/etc/mime.types` and then include the easy/documented way to update the application specific files. If a user adds their own types to /etc/mime.types it should be easy to reflect this in all apps, as you say a single source of truth.
- Adjust the nginx configuration to use this file rather than removing/over-writing a file which is installed by the nginx source package.

> Also I think thematically the apache package should undergo the same change as nginx, and rely on the single authoritative mime.types defined by the user's system.

This is an interesting point. It might be suitable for a desktop deployment, but it's not a great strategy for a server deployment, where you want more predictability.

I maintain several arch servers, both on-site and in the cloud. On some systems, we have a very specific/limited set of mime types by design, and this list only changes if there is an actual use-case for it. Other systems, it's irrelevant.

So, I started modifying my AUR packages to suit, but I still think

1/ It's silly of mailcap to include a mime file for nginx, because users without nginx will have some junk on their system.
2/ It makes more sense to have an explicit dependency e.g. mailcap-nginx

I'd like to see some resolution to this.

Okay, so I took matters into my own hands for my specific case.

https://aur.archlinux.org/packages/mailcap-mime-types/

It's basically mailcap but only the /etc/mime.types file, it's a direct replacement for the previous mime.types but based on mailcap.

It works for me and I think it's the simplest approach, since I'd prefer if the mime types for nginx were not the same as the system (it's unpredictable if it's changing and could be a security problem).

I don't know if it's been mentioned, but there was interesting discussion here https://bugzilla.redhat.com/show_bug.cgi?id=1248736 both sides of the coin fleshed out. I'm not sure if there is any "right" answer, but I think falling back on arch conventions of minimally invasive modifications to upstream packages is probably the best appraoch. One option might be to restore the `mime-types` package based on my `mailcap-mime-types` package above so things just basically work.

Seeing as this issue is still open after over a year, would it be possible to get some eyes on this?

I still firmly believe that the mailcap package currently violates Arch's packaging standards, as it includes files that are specific to another package (nginx, in this case).
Even if the case is made that it's convenient to have nginx's mime.types provided by mailcap, that still leads to inconsistencies with how other software is packaged (e.g. Apache is packaged with its own mime.types).

I realize that the severity of this is quite low compared to other open issues, but it would be nice to see it get addressed given the relatively low effort involved.

This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.