Mailbase emerge refuses to install if if finds any one of a number of files in /etc/pam.d. Surely this is something that should be handled in the normal Gentoo manner -- have these files updated by etc-update or dispatch-conf instead of having the user delete them? Furthermore, since the files in /etc/pam.d from uw-imap and mailbase only differ in their comments, the whole thing is pretty pointless. Reproducible: Always Steps to Reproduce: 1. emerge uw-imap (or similar, to create /etc/pam.d/pop and /etc/pam.d/imap) 2. emerge mailbase 3. Actual Results: Mailbase ebuild fails Expected Results: mailbase should continue and drop files in /etc/pam.d that will overwrite the existing files when etc-update or dispatch-conf is run.
You're asked to remove the files by hand. See Bug 79240 for the reasons.
I read the bug you pointed me to and it discusses the collisions and changes to various pop/imap packages, but it does not give any explanation of why the update of the pam.d/pop and other files should not be handled by the normal etc-update or dispatch-conf process.
Because it's not a normal upgrade path, but a change in the way these packages are handled. The message is there to tell you what you should do.
Carsten, the trouble is that the current solution is based on the assumption that everyone will use the files provided by mailbase, without any changes. If the only concern is moving from the files provided by the imap server package to the files provided by mailbase, this would make some sense...but that's not the only concern. Some of us have edited these files...in my case, it's so that my imap server can authenticate against mysql. So, for me, this solution means my emerge world dies every time there's a new version of mailbase, and I have to manually go in, move the files somewhere else, emerge the new mailbase, and move them back. I don't see any reason why the note couldn't simply be changed to explain why there's now a mailbase package and the fact that it now provides these files, and have it just add in the ._cfg0000 files. This is not going to be any more confusing to normal users (who are just now upgrading to the mailbase setup) than the current situation (and given that all the various imap servers seem to use pretty much identical files anyway....who cares?), and for those of us that actually want to change the config files, it won't be such a pain.
