/etc/mailcap contains "fake" entries for audio/basic, text/*, ...: audio/basic; /usr/lib/mime/playaudio '%s'; description=Basic uLaw Audio; nametemplate=%s.au text/*; gview '%s'; edit=gvim -f '%s'; compose=gvim -f '%s'; test=test "$DISPLAY" != "" text/*; view '%s'; edit=vim '%s'; compose=vim '%s'; needsterminal /usr/lib/mime/playaudio, gvim and vim do not exist on my system because I did not explicitly install those packages and they are not installed automatically (via dependencies). I'm using other alternatives (sox, nvi, ...) instead. I suggest you let each (installed) package provide it's own mailcap file and concatenate them together to /etc/mailcap, like Debian does.
I think this one needs real work that I can't do right now. Tossing back into the pool....
Sascha, If you could provide a bit more info (or a url) on how debian handles mailap entries that might be very helpful. Thanks!
The source for the Debian 'mime-support' package can be found on: http://ftp.debian.org/debian/pool/main/m/mime-support/mime-support_3.18-1.tar.gz Basically each package puts its mailcap entries into the file /usr/lib/mime/packages/<package-name> and runs update-mime on postinstall. update-mime concatenates (modulo some ordering logic defined in /etc/mailcap.order) those files to /etc/mailcap.
This should be a feature we add to portage. While the debian method may work, we can make it faster/better? While I haven't done any low-level coding with portage I think we should easily be able to make an update-mailcap script or an update-mailcap hook in portage. update-mailcap: reads files in /etc/mailcap.d which contains files which have the same name as the portage package name installed. These files contain lines which should be added to /etc/mailcap. for example: root# cat /etc/mailcap.d/xv # media-gfx/xv image/gif; xv %s image/jpg; xv %s Conflicting entries in mailcap can be a headache. If a user has multiple entries with the same mime type... you will get problems. I would assume that the best way to deal with conflicting types is to have update-mailcap check for duplicate mime types. When duplicate mime-types are found, display the conflicting entries and prompt the user to choose which one to use. Upon choosing one or neither to be added, the process continues looking for further conflicts or finishes parsing entries and writes the files output to /etc/mailcap. We could also set an option so that when conflicting entries are found, they aren't added so if people want to run an automated update script (via cron or something of the like) they still can... This also could possibly be something added to env-update parsing as well... adding a MAILCAP="blah" line to the files in /etc/env.d... I need more input on this from the actual portage developers.
drobbins, am I way off base or am I pushing in the right direction? This solution is also a possible solution for "Gentoo" menus in X Window Managers as well... parsing a file (/etc/env.d/* or some other appropriate directory) for variables and putting the output to a file to populate menu entries. Let me know what you think.
I like the Debian method of having an /etc/mailcap.order better. This way I only need to interact if a new package gets installed. Updates are fully automated. It's annoying enough to cycle through /etc/init.d/* etc. after updating. I don't want to put /etc/init.d into CONFIG_PROTECT_MASK, though, so I can still modify some of the files. Perhaps storing an MD5 of the original config file and comparing it during the update would be a good idea. But that's OT in this bug. ;)
Okay so the manual running of mailcap-update isn't perfect but I still don't think we should just take debian's solution. I think I like the idea of adding the support to env-update better as really the mailcap is "env" related. I have yet to look deeply into env-update as this is not something I am worried about getting into the 1.4 release. It's coming soon though. :)
Graham, can you hack up a perl script for us?
This bug is about to die from old age. I'm adding bug-wranglers to the CC list to see if anyone is interested in this or have any more input. Yeah, I'm the ass who's bumping up inactive bugs as if we don't have enough active ones, but a nice complete list of ancient bugs and forgotten feature requests is not of much use.
Isn't this they way env-update works? Each package provides a small bit of info in /etc/profile.d and env-update assembles them together?
Is an env-update approach better than nothing for now? I'm happy to have a go at putting one together. Maybe we can try that and see if we like it, then scrap it if its useless?
handled by net-mail/mailbase now
