Gentoo Archives: gentoo-dev

From: "Jared H. Hudson" <jhhudso@××××××××××.com>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] /usr/spool/mail versus maildir: use item needed
Date: Thu, 18 Apr 2002 22:44:01
Message-Id: 3CBF928C.2000007@volumehost.com
In Reply to: Re: [gentoo-dev] /usr/spool/mail versus maildir: use item needed by Thilo Bangert
1 For example in procmail right now, the procmail ebuilder uses sed to
2 edit the procmail source to use maildir at ~/.maildir instead of
3 /usr/spool/mail
4
5 I was going to add a use line so people can use the original mbox style
6 /var/spool/mail, or if they choose maildir let MAILDIR_PATH tell the sed
7 script what to change it to, that way it can be ~/Maildir or ~/.maildir
8
9 The same idea could apply to ebuild foo config when a user chooses to
10 let ebuild configure their email server, ect. Note this config is
11 optional and for most people would just be a start to configuring such
12 an app. For example ebuild php-* config adds php stuff to apache, but of
13 course anyone who runs apache is going to edit their config file as well
14 most likely.
15
16 -Jared H.
17
18 Thilo Bangert wrote:
19 > On Thursday, 18. April 2002 23:58, you wrote:
20 >
21 >>>>use items:
22 >>>>mbox and maildir
23 >>>
24 >>>what about the idea of just having one? (as they rarely will be
25 >>>used at the same time anyway)
26 >>>
27 >>>hhm, i guess you can compile pine with support for both.. (?)
28 >>
29 >>What do you mean just having one? It makes sense to me for a user to
30 >>put mbox or maildir in their USE items. Several programs, like pine,
31 >>procmail, ect can handle both formats. And with patches more programs
32 >>can handle both. So I think we need both use lines and have a user
33 >>choose one, otherwise the default for that package will be chosen.
34 >>
35 >
36 >
37 > yes, you are right.
38 >
39 >
40 >>I thought about the MAIL variable, and it would make sense, unless
41 >>you were wanting to compile for another machine, hence a specifically
42 >>defined MBOX_PATH or MAILDIR_PATH makes more sense, IMO.
43 >
44 >
45 > i don't know the package that uses this, as i can not think of why this
46 > would be a compile time variable...
47 >
48 > IMHO this should only be a runtime variable, because of the fact, that
49 > (at least in some cases) it is up to the user to decide
50 >
51 > so what package needs this?
52 >
53 >
54 >>-Jared H.
55 >>
56 >
57 >