I propose inclusion of the Mail::IMAPClient perl module. The module works well for accessing IMAP servers and we already do have its POP3 counterpart in portage Mail::POP3Client even though the modules are from different authors. :) I have attached (or will be attaching right after this report) an ebuild which works out of the box. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 38157 [details] Mail::IMAPClient ebuild This is my first ebuild submission so I hope everything is okay. It works flawlessly on a server I administer. Naturally I am open to any kind of suggestions and/or criticism. :-)
According to <http://www.gentoo.org/doc/en/policy.xml#doc_chap2> new perl modules are only added to portage if they meet one of the conditions mentioned there, most often the first (dependency of another package). Do you have some application using it not in portage? If so, write another ebuild for that app as well.
Unfortunately I haven't read the policy document before because I didn't know it exists. I use the Mail::IMAPClient module for some server scripts I have written. For now, I don't know of any perl application that depends on it too. Besides, it seems that this module can be handled by g-cpan, so I suggest closing this bug report without adding the ebuild to portage. Sorry for the inconvenience.
Maybe you can release those scripts, say, under GPL license, if they could be useful to broader range of people. :) As for the g-cpan.pl script, I was told that it is unusable at the moment, so that condition could be striked off, I guess. Feel free to reopen this bug when/if you submit an ebuild for those scripts of yours, with this here ebuild as a dependency.
For now, it's just one script I wrote which requires Mail::IMAPClient and I don't know if it would be useful to anyone else. Releasing it under a GPL license would be no problem. It's basically a perl cron script which checks specified IMAP folders (e.g. 'false negatives' and 'false positives') and uses that msgs to learn the spamassassin bayes filter. Before I could release that, I would have to clean it up a bit and rewrite some parts, to make it more flexible/configurable. The main reason I wrote that script is, there is no other way to access IMAP folders and delete msgs without trashing the IMAP mail directory. (except for writing your own little client but I guess my variant is a bit simpler than that and besides, the IMAP server and SpamAssassin server can be on different machines) And for the g-cpan.pl: well, I haven't tried it to the end. Just read what it does and assumed it will work for this purpose. :-)
