Hi guys, /usr/bin/maildirmake is provided by both courier-imap and maildrop (possibly courier as well?). This should probably be fix0red, no?
and somemore, but I don't have a *clean* solution yet. 1. Don't install if exist. Problem: user unmerges the package provides the binaries then maildrop doesn't have maildirmake, etc... anymore 2. Rename binaries. Sound more like a hack. 3. Whinning at upstream so they pack everything in /usr/bin/ as courier-maildir-utils and DEPEND courier-* on it. Already try with something else, got no response. Any recommend?
danger will robinson. it is also provided by qmail, but the ones provided by courier* and qmail and subtley different. the courier ones do the Maildir++ format, while the original qmail one just does the stock Maildir format. The Maildir++ format is completely backwards compatible, and should be preferred. as the ones provided by courier-imap, maildrop, courier are identical (they are the same CVS source base). I'm all for the courier-utils solution, even if we do it ourselves (not that hard).
the same is true for maildrop, apparently, as per bug 69359
Shouldn't this be [able to be anyway] handled by mailwrapper? Perhaps we just need to make it a little fussier about not letting multiple builds that provide maildirmake be allowed to coexist without the wrapper.
I think the best solution is to bring out a seperate maildirmake, that implements the Maildir++ stuff, since that is backwards compatiable with the regular Maildir. The only downside of this is basically we end up maintaining our own tarballs of maildirmake (from the stuff in the courier CVS). This solution works well as then other Maildir-based MTA's can use it as well (there are more than just courier* and qmail).
So lads, what's the progress on this then?
seemant: I haven't heard from langthang/swtaylor in a very long time.
(In reply to comment #7) > seemant: I haven't heard from langthang/swtaylor in a very long time. I don't work on courier-* anymore. BTW, I think iggy took over maintainership of courier. Iam not sure if he is on net-mail alias, so CC'ing him for comment.
Courier blocks virtual/imapd (courier-imap), virtual/mta (qmail), and maildrop. If you guys want to cook up your own maildirmake feel free, and I'll dep on it, and stop installing it with courier.
Ok... I managed to build a standalone maildirmake. http://dev.gentoo.org/~ferdy/overlay/net-mail/maildirmake It is working fine for me. Does it look ok to all of you ? Any other things to include in that package ? Cheers, Ferdy
So - what's the progress here? Just did hit this annoyance again.
ferdy, yep this seems to work for me -- can you add ~amd64 to it?
*** Bug 129469 has been marked as a duplicate of this bug. ***
ferdy: ACK from me for putting that maildirmake into the tree.
*** Bug 158400 has been marked as a duplicate of this bug. ***
Ping Come-on guys, two and a half years?
Suggestion for an (interim) solution: Have maildirmake as a USE flag on each of the packages that provides it. That way the user can choose which implementation they wish to use. Don't forget to put the maildirmake man pages under that flag too as that's what actually conflicts on (net)qmail.
Created attachment 115906 [details, diff] Patch for courier-imap ebuild against 4.0.6-r2 This is a patch that adds the maildirmake USE flag to the courier-imap-4.0.6-r2 ebuild.
Created attachment 115912 [details, diff] Patch for netqmail against 1.05-r7 This is a patch that adds the maildirmake USE flag to the netqmail-1.05-r7 ebuild. I decided to do the maildirmake USE flag operations at the end of the install phase instead of messing with the install operations earlier primarily because it makes dealing with cases where another implementation of maildirmake isn't installed yet far easier.
*** Bug 203167 has been marked as a duplicate of this bug. ***
And 3 1/2 years later... eh.
I've ran into this problem now, too (with maildrop and courier-imap). Additionally, updating one or the other package may switch implementations. FEATURES="collision-protect" even breaks emerge and leaves me with one package not updateable. I would prefer a USE flag solution as the cleanest one - leaving the user the option which implementation to use. Just make sure that only one of all colliding packages enable this use flag.
A use flag solution to this problem is a mess and not correct. Can we do what robbat2 suggested and use the one that supplies the backwards compatible solution? Its the cleanest, even if we have to maintain it ourselves. net-mail: Comments?
*** Bug 203947 has been marked as a duplicate of this bug. ***
*** Bug 207264 has been marked as a duplicate of this bug. ***
ferdy: Could we put your standalone maildirmake into the tree and get everything else updated to stop installing maildirmake and dep on yours? Is this alright with everyone? This bug is *old* and I want to see it go away :)
(In reply to comment #26) > Is this alright with everyone? This bug is *old* and I want to see it go away > :) Yeah, sure... +1, this bug is very annoying.
*** Bug 207806 has been marked as a duplicate of this bug. ***
Created attachment 144710 [details] maildirmake-0.1.ebuild This one handles autotools properly...
Gah, should use dohtml instead, and missing quotes around ${S}. Anyway, it works. :)
Created attachment 144711 [details] maildirmake-0.1.ebuild
Seeing as this bug has gone on for several years now, I've decided to create a solution for myself and share it with the community. The attached ebuild adds a 'nomaildirmake' use flag which, if enabled, will remove all files relating to maildirmake from the image before it merges with /.
Created attachment 147638 [details] updated maildrop ebuild adds a 'nomaildirmake' use flag removes maildirmake files if enabled
Created attachment 147640 [details] updated ebuild updated to catch several other files colliding with courier-imap
*** Bug 251429 has been marked as a duplicate of this bug. ***
*** Bug 226161 has been marked as a duplicate of this bug. ***
*** Bug 253836 has been marked as a duplicate of this bug. ***
Just hit this very same bug. More than four and a half year now... congratulations. Is there anyone willing to do anything ?
+1 plz fix it
just hit this ugly BUG (qmail vs courier-imap)
FEATURES="-collision-protect -protect-owned" emerge maildrop
*** Bug 277757 has been marked as a duplicate of this bug. ***
*** Bug 286291 has been marked as a duplicate of this bug. ***
hit (again) by this bug. Sure i can FEATURES="-collision-protect -protect-owned" emerge maildrop .... but this is a turnaround.
Created attachment 209109 [details] Added tools use flag to exclude maildirmake and deliverquota So maildrop 2.2.0 is stable and it's still not fixed. I also wonder why courier-imap does not install maildrop itself? http://www.courier-mta.org/maildrop/ > You do not need to download maildrop from here > if you already have the Courier mail server installed. Anyway, I adapted the "nomaildirmake" fix to the newest ebuilds without problem. I changed the use flag to "tools", so you'll have to USE="-tools" to install maildrop without maildirmake and deliverquota. You need to copy files/maildrop-2.2.0-db4.patch to your overlay also. # USE="-tools" emerge -1 =mail-filter/maildrop-2.2.0-r1
*** Bug 291733 has been marked as a duplicate of this bug. ***
Just hit this one with * Detected file collision(s): * * /usr/share/man/man1/maildirmake.1.bz2 * /usr/share/man/man5/maildir.5.bz2 <snip> * mail-mta/netqmail-1.06 Not sure about the manpages but maybe just leave them out?
*** Bug 295845 has been marked as a duplicate of this bug. ***
*** Bug 296134 has been marked as a duplicate of this bug. ***
*** Bug 304801 has been marked as a duplicate of this bug. ***
Is this really resolved? I just encountered this on a fresh new build of gentoo? Resolved tells me that the solution is in the stock tree. The supplied ebuild attached to this bug is a workaround because now I have to go set up an overlay first. This bug has been haunting qmail for *5 1/2* years now. First it was qmail, then netqmail (what I used and got around it by unmasking the ~arch version (x86 in my case)) and then ran into again w/ courier-imap. Come on!?! This all is floating around 1 tool (makemaildir) in my case (and in some others 2 (from this list)) So is someone working to make sure this is *correctly* resolved?
*** Bug 308917 has been marked as a duplicate of this bug. ***
Wow. All I can say is... wow. Over 5 years this bug is just hanging out there stinking -- and I actually wasted my own time on it. I feel like an idiot. Here, I'll waste more of my time: The first comment is just, plainly, wrong. Can we close this bug, open a new one and fix it, please? I mean, did this guy Tuan Van actually run a mailserver, or just twiddle ebuilds... or what? I mean: "1. Don't install if exist." -- This is the approach I take. It works. [Who the hell sets up a mailserver just to remove it anyway? You spend hours twiddling configs and say, oh I didn't want that anyway..??] "Problem: user unmerges the package provides the binaries then maildrop doesn't have maildirmake, etc... anymore" -- WHAT THE HELL!?!? WHO CARES?!?!? I NEVER USE THESE STUPID UTILS ANYWAY AND NEITHER DOES ANYONE ELSE NEEDING THIS PACKAGE. WE GET IT FOR MAIL****DROP**** [need bigger caps there] and my email client makes the !@#$%^&* folders. Like 99.9% of all IMAP installations. ... hello?... reality check? ... Anyone?? Why this wasn't addressed properly like so 5 years ago is... I mean, like, most of the folks commenting here are retired? Can we just stop blaming the ancients for current inaction (by reassigning bugs to here, where nothing happens for years)? These arguments against fixing it are just bogus. These people with bogus arguments, furthermore, are gone. Current developers have little reason to ignore this -- *excepting this bug and the bogus arguments attached*. Please just make it so we can emerge the package, or put something explanatory in the ebuild to spit out a *known workaround* (with an apology on behalf of whoever you blame) when it fails to merge. Or close the bug as WONTFIX (too lazy), but please... DO *SOMETHING*!!!
(In reply to comment #53) > Wow. All I can say is... wow. Still puzzled by this one. Now over being truly amazed at the dumping of random related bugs to this dubious string, some other thoughts: > I mean: > > "1. Don't install if exist." If this is ever possibly going to be a problem to a user moving forward, then folks can simply spit out a warning at the end of the ebuild merge, like: "maildirmake binary and some related documentation was found on your system, this package "maildrop" also provides it... blah blah.... if you break your system, reinstall maildrop" I still *really doubt* that anyone would remove a mailserver package like courier-imap (or other that installs maildirmake binary, info and dirquota info) would then *wonder why* maildirmake was missing... or why they'd even notice. And then if they re-install maildrop, they will get missing items back... as they wont be on the system..?? Now, it is possible someone would use maildrop w/o an IMAP server -- and they will never see a package collision. I can see someone deciding to remove an IMAP server, but then continuing to use a client that reads maildir format locally, with fetchmail and maildrop. But, that person can probably figure out what happened and I don't believe maildrop will lose mail in any case... plus, this would be such a "corner" case, is it really blocking fixing AT LEAST maildrop? AND I can't think of anyone who would do that, for whatever reason, who wouldn't also be fine with re-emerging such a trivial package as maildrop. Apologies to anyone who was possibly offended by the tone of exasperation in my earlier post, but... I still can't believe no one has fixed this. No one *likes* filing a bug, AFAIK. It's abusive to the users, for over five years, not to have done something -- IMO as a user. '-/ BTW, FWIU maildrop is according to some (probably the author), a more sane replacement for procmail... Google the two to see. I doubt procmail will be removed from portage anytime, but anyone wanting to adjust to a "better" method with maildrop will run into this problem, I think. It doesn't seem really that hard to just fix the maildrop ebuild and warn the user, if you all *really* think it's needed.
Created attachment 226731 [details] Added tools use flag to exclude maildirmake and deliverquota This is a new version of my previous ebuild. Use with "-tools" to not install maildirmake and deliverquota from this package. I really hope this get properly fixed sometime in my lifetime :-)
Amazing... this of one the things (like this bug being not solved for years...) why I'm trying to convince my Boss to drop Gentoo as linux solution in the company... Cause, in work time, is a serious lost of time by trying to implement this.
(In reply to comment #56) > Amazing... this of one the things (like this bug being not solved for years...) > why I'm trying to convince my Boss to drop Gentoo as linux solution in the > company... > Cause, in work time, is a serious lost of time by trying to implement this. > Forgot to mention that in Gentoo wiki mentions the use of mailbot in replace of maildrop that comes with courier (if we have courier installed) http://en.gentoo-wiki.com/wiki/Maildrop
(In reply to comment #55) > Created an attachment (id=226731) [details] > Added tools use flag to exclude maildirmake and deliverquota > > This is a new version of my previous ebuild. Use with "-tools" to not install > maildirmake and deliverquota from this package. +1 for getting Marcel's ebuild into portage
hm, almost 6 years now, anything new on this?
*** Bug 324313 has been marked as a duplicate of this bug. ***
The ebuild from Comment #55 works great for me! Please add this to the tree!
i keep on getting hit by this bug, it's been reported and confirmed back since 2004 :-(
(In reply to comment #62) > i keep on getting hit by this bug, it's been reported and confirmed back since > 2004 :-( > Another ebuild (2.5.1) is in the tree, still has the same dumb-ass behavior. It still isn't handled. It boggles the mind, really. Thanks to Marcel for a nice hack to fix it. Now, who is going to close a bug this old with something that works? Marcel's bits still do the trick. diff for 2.5.1 ebuild, fwiw: 18c18 < IUSE="berkdb debug fam gdbm ldap mysql postgres authlib" --- > IUSE="berkdb debug fam gdbm ldap mysql postgres authlib +tools" 101a102,110 > if ! use tools ; then > for tool in "maildirmake" "deliverquota"; do > rm "${D}/usr/bin/${tool}" > rm "${D}/usr/share/man/man"[0-9]"/${tool}."[0-9] > rm "${D}/usr/share/maildrop/html/${tool}.html" > done > # rm "${D}/usr/bin/makedatprog" > fi >
The problem persists with net-mail/courier-imap-4.5.0 and mail-mta/netqmail-1.06
The original summary for this bug was longer than 255 characters, and so it was truncated when Bugzilla was upgraded. The original summary was: File collision: maildirmake + related manpages (/usr/bin/maildirmake /usr/share/man/man1/maildirmake.1 /usr/share/man/man5/maildir.5 /usr/share/man/man8/deliverquota.8) provided by multiple packages (mail-filter/maildrop, mail-mta/netqmail, net-mail/courier-imap)
While we're waiting on a fix to an almost 7 year old bug, perhaps the HowTo (http://www.gentoo.org/doc/en/qmail-howto.xml) could be updated? As a relative n00b to Gentoo, I wanted to install and configure mail and now I'm stuck and not sure how to proceed.
The simple workaround is to delete the offending duplicate file off your filesystem. I don't know if this will cause any problems, but that's how I dealt with it and it didn't cause any.
This is not a good solution but it is better than status quo. So: + 27 Jul 2011; Eray Aslan <eras@gentoo.org> maildrop-2.5.4.ebuild: + Tie colliding files to tools USE flag - bugs #61116 #374009 +
