Some people need or want to have their own default parameters passed to bittorrent (max_uploads, max_upload_rate, etc), so they have to edit the application/x-bittorrent entry /etc/mailcap accordingly. The pkg_postinst() in the bittorrent ebuild just wipes out any bittorrent entry in /etc/mailcap and replaces it with its default. While bittorrent isn't a frequently updated package, this still means that whenever an update is emerged, any changes made to the mailcap entry are lost and need to be re-added manually. Perhaps the next revision of the bittorrent ebuild should instead copy the existing /etc/mailcap to /etc/._cfgetcetc_mailcap, do its sed work on the _cfg file, and then leave it to the the sysadmin to decide via etc-update if the changes to the application/x-bittorrent line should take place?
Now it copies /etc/mailcap and puts the modified version in its installation tree. This should lead to the default portage behaviour for a modified /etc/mailcap - even if this seemed sometimes a bit strange when I played around with it. Please give it a try and report.
It works just as you described, /etc/mailcap now shows up in etc-update's list and allows choice of merging or discarding the changes to the bittorrent entry. Thanks Patrick.
Ok, closing this bug.
have to re-open in order to set it to fixed
fixed
No package should overwrite file owned by another package (net-mail/mailbase in this case). I propose a different solution - mailbase will provide /etc/mailcap file with correct application/x-bittorrent entry accordingly: net-mail/mailbase-1-r1 for <=bittorrent-4.1.3 (old naming scheme, bt*.py) net-mail/mailbase-2 for >=bittorrent-4.1.4 (new naming scheme) Bittorrent ebuilds can then RDEPEND on appropriate mailbase version, and will stop messing with the mailcap file. Any suggestions or corrections?
net-p2p, please review my previous comment, and state your opinion.
i've removed the mailcap entry from bittorrent ebuild. handling mime type is now done in .desktop file
