emerge continues to kill /var/spool/postfix/maildrop when unmerging the old version of postfix. A .keep file is not viable in that dir because of how postfix operates; portage needs some other way to make sure that dir is not removed -- or the postfix ebuild need to make use of such another way if one already exists.
did you try this ? --- postfix-2.0.19.ebuild 26 Mar 2004 20:48:17 -0000 1.5 +++ postfix-2.0.19.ebuild 10 Apr 2004 15:01:54 -0000 @@ -153,6 +153,7 @@ rm -rf "${D}/var" keepdir /var/spool/postfix + keepdir /var/spool/postfix/maildrop # Provide another link for legacy FSH. dosym /usr/sbin/sendmail /usr/lib/sendmail
What version? I am fairly sure this is fixed in 2.0.19. Martin, we can't keepdir because postfix complains about corrupted files in the queue (.keep).
James, can you please verify the version of postfix that was giving you problems? I just emerged postfix 2.0.19, verified that the /var/spool/postfix/maildrop dir was created. Then I ran "emerge unmerge postfix", and all the directories in /var/spool/postfix remained, including the maildrop folder. I think this issue is resolved.
Ajay, James: I believe the problem is this: that directory on James' computer has always been empty. What portage does is this: it merges a new set of files and directories over the old. Then it reads the CONTENTS file from the previous version in order to know what to remove. Well, the CONTENTS file contains atimes. However, atimes do not work with directories at all (see the abundance of .keep files all over your portage tree, for example). Thus, unless that directory contains *some* file, it will get removed on upgrade. There are two ways around this: one is to put a .keep file in there (keepdir /var/spool/postfix/maildrop in the src_install function); the other is to rmdir it in src_install and mkdir it in pkg_postinst right into the filesystem. I favour the first method, however postfix might not like an empty file named .keep in its maildrop-spool directory. So, let's be creative people -- what can we do about this?
The actual error you get when there's a .keep file in /var/spool/postfix/maildrop: postfix/postsuper[18871]: warning: bogus file name: maildrop/.keep And you get this when postfix starts or if you do a 'postfix reload'. That's probably going spark more questions/bugs/etc. I think we're going to have to go the rmdir/mkdir route unless there's a better idea (patching postfix to ignore the .keep file??)
I believe this issue have been fix since postfix-2.0.19 so unless you upgrade from <postfix-2.1.18 /var/spool/postfix/* won't be removed. [code] rm -rf "${D}/var" keepdir /var/spool/postfix [/code] I really don't know how to fix this bug to allow people upgrade from postfix-2.0.18. From >=postfix-2.0.19, all the queue directories create by post-install in pkg-postinst, then it will be removed during unmerge <=postfix-2.0.18. I am not sure if rmdir in src_install then mkdir in pkg_postinst will work. CC dev-portage to see if they can give us some more ideas. I don't want to bump postfix without close this bug first.
After some testing/trying, I think there is no *clean* solution to fix this bug util bug 16162 get fixed. It is easy enough to run `/etc/postfix/post-install upgrade-permissions` to create all of the queue directories. I'll make the ebuild to put out warnings/instructions as a workaround for now.
Just a thought: would it make sense to put /var/spool/postfix in cfgpro? Like a config file, you wouldn't necessarily want queue files blindly deleted. Of course, they're already protected by the fact that they're not in the package, but perhaps putting it cfgpro is in keeping with the spirit of cfgpro, doesn't hurt anything, and solves this problem?
pkg_postinst() { PORTAGE_HACK="${ROOT}/var/spool/postfix/maildrop/.keep" [ -e $PORTAGE_HACK ] && rm -f $PORTAGE_HACK }
As far as I can see, this has been fixed at least from the 2.1.5-r2 in portage, via a "keepdir /var/spool/postfix". Reading the ChangeLog, this should have disappeared and seems not to have been readded, but nevertheless it's there in all ebuild... I added Max Kalika as Cc: to have some input on the move dated 1/14/2004.
I didn't know this was still open. AFAICT it is indeed fixed.
(In reply to comment #11) > I didn't know this was still open. > > AFAICT it is indeed fixed. > Ok then. Thanks, Tuan
