Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 52076 - GLEP 32: Maildir location
Summary: GLEP 32: Maildir location
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: GLEP Editors
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 472746
  Show dependency tree
 
Reported: 2004-05-26 03:51 UTC by Georgi Georgiev
Modified: 2022-07-15 18:39 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
maildir.eclass (maildir.eclass,794 bytes, text/plain)
2004-05-26 03:52 UTC, Georgi Georgiev
Details
maildir.diff (maildir.diff,24.45 KB, patch)
2004-05-26 03:54 UTC, Georgi Georgiev
Details | Diff
vpopmail.diff (maildir.diff2,1.29 KB, patch)
2004-05-26 04:01 UTC, Georgi Georgiev
Details | Diff
maildir.eclass (maildir.eclass,420 bytes, text/plain)
2004-11-03 03:36 UTC, Georgi Georgiev
Details
maildir.diff (maildir.diff,30.83 KB, patch)
2004-11-03 03:38 UTC, Georgi Georgiev
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Georgi Georgiev 2004-05-26 03:51:50 UTC
Dear gentoo devs,

I, like many others, have been frustrated with the choice for the default maildir name on a gentoo system. I do not want to go in a flamewar over the matter, though. I'd rather like to propose a method that will make me and others like me who prefer to use "Maildir" happy, and all the other folk, who believe that ".maildir" is a better name happy, plus whoever else prefers some other name (".mail", ".Maildir", "Mail" anyone?).

I propose the introduction of a MAILDIR variable to make.conf. The value of this variable would default to ".maildir" for backwards compatibility. All ebuilds that have ".maildir" hard-coded at the moment, can use ${MAILDIR} instead.

I coded a maildir.eclass that would set the default MAILDIR value, and it also provides a few helper scripts to make those fixes easier.

I also patched the newest ebuilds from $PORTDIR/net-mail that referenced ".maildir" to use maildir.eclass and install according to $MAILDIR.

Please see that this issue gets fixed. I know it will make many users happy.
Comment 1 Georgi Georgiev 2004-05-26 03:52:33 UTC
Created attachment 32060 [details]
maildir.eclass

The maildir.eclass that makes installations easy.
Comment 2 Georgi Georgiev 2004-05-26 03:54:50 UTC
Created attachment 32062 [details, diff]
maildir.diff

A patch against all newest ebuilds in $PORTDIR/net-mail that reference
".maildir". Includes fixes for:

bincimap-1.2.7-r1.ebuild
checkpw-1.01.ebuild
courier-imap-3.0.4-r1.ebuild
courier-0.45.5.ebuild
dovecot-0.99.10.4.ebuild
exim-4.34.ebuild
maildrop-1.5.3-r1.ebuild
mailfront-0.88.ebuild
mutt-1.5.6-r1.ebuild
nail-9.30.ebuild
popa3d-0.6.4.ebuild
postfix-2.0.19-r2.ebuild
procmail-3.22-r6.ebuild
qmail-ldap-1.03-r4.ebuild
qmail-mysql-1.03-r13.ebuild
qmail-1.03-r15.ebuild
qmailadmin-1.2.1.ebuild
vpopmail-5.4.0.ebuild

Attaching the diffs one by one is too tiring.
Comment 3 Georgi Georgiev 2004-05-26 04:01:37 UTC
Created attachment 32063 [details, diff]
vpopmail.diff

I know I should never make last-minute-changes... but I still do. Here is a
fixed patch for the vpopmail.ebuild.
Comment 4 Grant Goodyear (RETIRED) gentoo-dev 2004-05-26 09:23:06 UTC
Since you are proposing a change in our default policy, to some extent, a GLEP 
is almost certainly warranted.  (See http://glep.gentoo.org.)

I think this idea is a good one (although I would prefer that the default maildir
location be specified in rc.conf instead of make.conf).
Comment 5 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2004-05-26 10:31:03 UTC
as grant as said, this needs to go thru a GLEP most definetly.
i'll say right now that i'm against having a variable for people to use easily for it, i'm 100% we'll get some people that start installing things with .maildir, then change it to something else, and don't re-merge the packages that need the contents of the variable at compile time, and will file bugs complaining it doesn't work.
Comment 6 Georgi Georgiev 2004-05-26 18:23:27 UTC
At first I thought about proposing a mail-config tool -- something similar to webapp-config and config-kernel. This tool could take care of changing the default value of the directory, possibly recompiling necessary packages, etc.

I, however, realized that I am more likely to get attention if I propose something that can quickly be implemented, hence the variable and the patches.

If you state your concerns clearly, we should be able to work them out. For now, what I see is:

1. GLEP
2. Prevent users from shooting themselves in the leg

I guess a GLEP should wait until we address the number 2 issue.

Regarding number 2: What do you think of a mail-config?

# config-mail --set-maildir Maildir
Your current default maildir location is ".maildir".
* You'll need to recompile the following packages and merge the configuration changes:
(list of packages)
* In addition you need to make sure the configuration of the following packages is correct (or you should remerge them and merge the proposed changes):
(list of packages)

Well?
Comment 7 Grant Goodyear (RETIRED) gentoo-dev 2004-06-06 11:53:14 UTC
I think your proposal is overly-complicated, when a DEFAULT_MAILDROP variable
(or some such) in /etc/rc.conf really ought to suffice.  (Of course, every
package that delivers mail would then have to be patched to use it.)
Since I would expect
very few people to ever change the value of this variable, I'm not so worried
about people shooting themselves in the foot.
Comment 8 Georgi Georgiev 2004-06-06 12:14:55 UTC
This only makes me happy.

1. the original proposal suggests only a variable (I don't care where it is set)
2. patches for the packages are already attached

I guess it's about time I wrote that GLEP to find out if protecting the users is going to be an issue (comment #5).
Comment 9 Georgi Georgiev 2004-11-03 03:36:45 UTC
Created attachment 43210 [details]
maildir.eclass

A version of the maildir.eclass that reads in and exports a variable from
/etc/rc.conf
Comment 10 Georgi Georgiev 2004-11-03 03:38:06 UTC
Created attachment 43211 [details, diff]
maildir.diff

A diff against all current packages to use the maildir.eclass

Just getting ready for the GLEP.
Comment 11 Elan Ruusamäe 2004-11-04 02:48:23 UTC
what about having the MAILDIR in /etc/env.d directory, and let all apps use it, with some sane default (.maildir/, but i'd prefair Maildir/)

Comment 12 Georgi Georgiev 2004-11-04 03:18:24 UTC
I was guessing that the variable should only be available at compile-time. That is why I suggested make.conf, but rc.conf is just as good. I am sure that I am not seeing something obvious, but I don't like the idea of the variable being constantly exported.

The reason why this gives me the creeps is probably because having the variable in env.d would make users assume that it is safe to change the variable. And it is definitely NOT so. (Or is it?). I mean, if one changes this variable, they'd need to recompile the packages that have the old value hardcoded (at compile time), fix their configuration files (delivery rules in home directory) that reference the old value, and also rename their current maildirs.

If you do need the variable for some package you can always source rc.conf and get it.
Comment 13 Georgi Georgiev 2004-11-13 00:57:32 UTC
OK, net-mail herd,

It seems that there is nothing left to be desired from the discussion on the gentoo-dev list. If you are worried about manpower -- I'm willing to submit patches for ebuilds as long as it is needed, and it is completely within my abilities to do so.

My last remaining concern is the rc.conf v.s. make.conf issue. For those of you who missed the post on gentoo-dev:

 The MAILDIR variable changes the way packages are installed.
 Therefore, if someone wants to consistently reinstall their system,
 they would also need a copy of rc.conf. It seems that rc.conf is intended
 for runtime configuration of applications only. Therefore, it may not
 be a good idea to store the variable there.

Secondly, we'll need a representative to present GLEP 32 on a manager meeting (not necessarily the next one)... I am not a dev, so I don't know what the procedure is, but if somebody wants to volunteer, please do.

If someone wants to take a look at my maildir overlay:

rsync://rsync.gg3.net/gentoo-portage-maildir
Comment 14 Cory Visi (RETIRED) gentoo-dev 2006-05-25 14:01:14 UTC
Georgi, it's been awhile, do you still have the time and motivation to help with this?  I'm willing to move it forward with you if you want.  I prefer ~/Maildir as well.
Comment 15 Georgi Georgiev 2006-05-26 23:12:29 UTC
(In reply to comment #14)
> Georgi, it's been awhile, do you still have the time and motivation to help
> with this?  I'm willing to move it forward with you if you want.  I prefer
> ~/Maildir as well.

Sure thing. I just synced my overlay with the portage tree last week, so it should be more or less ready for review.

rsync://rsync.gg3.net/gentoo-local/maildir

I'll be more than happy to assist with anything.

I'm "chutz" on irc BTW.
Comment 16 Eray Aslan gentoo-dev 2011-05-06 18:55:40 UTC
I am not so sure whether this is such a good idea.  Just change the config files in whatever package you use if you want to change to default maildir location.  Closing.
Comment 17 Kalin KOZHUHAROV 2011-05-07 00:44:30 UTC
Eray,

I am sure you prefer to have less bugs open for the things you maintain, but:

(In reply to comment #16)
> I am not so sure whether this is such a good idea.

is definitely NOT a sufficient reasoning to close a bug, don't you think so?

I am wondering if you read the whole discussion, together with GLEP 32?

> Just change the config files in whatever package you use if you want
> to change to default maildir location.

and do that on ALL machines, EVERY TIME you re-emerge ANY mail related package?!? Better not forget to do so, and of course NEVER use `emerge world` as it will break your systems badly.

Gentoo used to be about flexibility when we started using it 7 (?) years ago. At least for me it is still the sole reason to use. Having a consistent default is a very good thing, but hard-coding it and forcing it is NOT.

Please re-consider your decision and see if you can help this bug instead.
Comment 18 Eray Aslan gentoo-dev 2011-05-07 04:06:05 UTC
(In reply to comment #17)
> is definitely NOT a sufficient reasoning to close a bug, don't you think so?

No, I don't.  It will be a maintenance burden with questionable benefit.

> and do that on ALL machines, EVERY TIME you re-emerge ANY mail related
> package?!?  Better not forget to do so, and of course NEVER use `emerge world`
> as it will break your systems badly.

Use cfengine, puppet, whatever if you manage several machines.  emerge world or emerging a package will not break your system.  If it does, file a bug and CONFIG_PROTECT your config file.

> Gentoo used to be about flexibility when we started using it 7 (?) years ago.

This isn't about choice.  This is about distributing the work between gentoo developers and sysadmins.  Well, I want to help if I can but this is too much hand holding for my taste.
Comment 19 Eray Aslan gentoo-dev 2011-05-07 04:15:58 UTC
On second thought, re-opening it.  If you want to get rid of hard-coded maildir locations, you will need to find someone else to make the changes tho.
Comment 20 Georgi Georgiev 2012-03-16 14:33:21 UTC
(In reply to comment #18)
> 
> Use cfengine, puppet, whatever if you manage several machines.  emerge world
> or emerging a package will not break your system.  If it does, file a bug
> and CONFIG_PROTECT your config file.

I started this whole thing because I encountered some packages that were only able of using the "Maildir" location defined at compile time. Can't remember which ones (it's been more than half a decade already) and maybe it is not true anymore.

I will take your advice and will try to upgrade from the official repository. If puppet, which I am using anyway, solves the problem then I'll give up on GLEP 32.

It was the advent of the "qmail" eclass that made me feel like I am losing the battle with the ebuilds. Before its time I only had to apply a couple of trivial patches to the ebuilds, but maintaining a patched eclass in an overlay is something I don't want to risk.
Comment 21 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-07-06 19:53:37 UTC
(In reply to Eray Aslan from comment #19)
> If you want to get rid of hard-coded maildir locations, you will need to find someone else to make the changes tho.