Re: [PATCH 0/4] Allow specifying alternate names for addresses in other_email
[notmuch-archives.git] / 27 / 18ec5f837d79a3d39f44780f8bcc27936e78fe
1 Return-Path: <blakej@foo.net>\r
2 X-Original-To: notmuch@notmuchmail.org\r
3 Delivered-To: notmuch@notmuchmail.org\r
4 Received: from localhost (localhost [127.0.0.1])\r
5         by olra.theworths.org (Postfix) with ESMTP id D0AA4431FAF\r
6         for <notmuch@notmuchmail.org>; Sun,  4 Nov 2012 21:27:07 -0800 (PST)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: 0\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
12         autolearn=disabled\r
13 Received: from olra.theworths.org ([127.0.0.1])\r
14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
15         with ESMTP id VZBn+WYr7JpI for <notmuch@notmuchmail.org>;\r
16         Sun,  4 Nov 2012 21:27:07 -0800 (PST)\r
17 Received: from foo.net (70-36-235-136.dsl.static.sonic.net [70.36.235.136])\r
18         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
19         (No client certificate requested)\r
20         by olra.theworths.org (Postfix) with ESMTPS id 1733D431FAE\r
21         for <notmuch@notmuchmail.org>; Sun,  4 Nov 2012 21:27:07 -0800 (PST)\r
22 Received: from foo.net (localhost [127.0.0.1])\r
23         by foo.net (8.14.5+Sun/8.14.5) with ESMTP id qA55R4m9013730;\r
24         Sun, 4 Nov 2012 21:27:04 -0800 (PST)\r
25 To: Jani Nikula <jani@nikula.org>\r
26 Subject: Re: [PATCH 05/10] install: check for non-SysV version (Solaris\r
27         support) \r
28 In-Reply-To: Your message of "Sun, 04 Nov 2012 23:31:02 +0200."\r
29         <87d2ztf42x.fsf@nikula.org> \r
30 Date: Sun, 04 Nov 2012 21:27:04 -0800\r
31 Message-ID: <13729.1352093224@foo.net>\r
32 From: Blake Jones <blakej@foo.net>\r
33 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2\r
34         (foo.net [127.0.0.1]); Sun, 04 Nov 2012 21:27:04 -0800 (PST)\r
35 Cc: notmuch@notmuchmail.org\r
36 X-BeenThere: notmuch@notmuchmail.org\r
37 X-Mailman-Version: 2.1.13\r
38 Precedence: list\r
39 List-Id: "Use and development of the notmuch mail system."\r
40         <notmuch.notmuchmail.org>\r
41 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
42         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
43 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
44 List-Post: <mailto:notmuch@notmuchmail.org>\r
45 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
46 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
47         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
48 X-List-Received-Date: Mon, 05 Nov 2012 05:27:08 -0000\r
49 \r
50 > > +INSTALL="install"\r
51 > > +printf "Checking for working \"install\" program... "\r
52 > > +mkdir _tmp_\r
53\r
54 > This doesn't feel like a hot idea.\r
55 \r
56 Out of curiosity, why not?  An "install" that behaves as expected is\r
57 one of the first things that an autoconf-generated "configure" looks\r
58 for.  Now, autoconf-configure implements that check using some\r
59 assumptions about where things are on different operating systems,\r
60 but that sort of check runs the risk of becoming stale (see below).\r
61 \r
62 > Don't tell me you'd need to create a compatibility script for using\r
63 > mktemp --tmpdir too...\r
64 \r
65 Yes I would, if it were used; not all the world's a GNU.  But in the\r
66 case of mktemp, the widely available "-p" and "-t" options seem to get\r
67 you most of the way there.  The SVR4 "install" in Solaris' /usr/sbin is\r
68 different enough from the BSD/GNU versions that I wouldn't want to try\r
69 to emulate it with a wrapper.\r
70 \r
71 > Or how about just always using ginstall on Solaris?\r
72 \r
73 I'd rather not do that.  With the old UCB tools having been EOL'ed [1],\r
74 /usr/ucb/install (which would have worked) will be going away.  There is\r
75 an open bug in the Sun bug tracking system about moving GNU install to\r
76 /usr/bin/install, specifically motivated by this change.  So while I\r
77 don't know if/when that bug will be fixed, I would guess [2] that a\r
78 future release of Solaris may have a BSD/GNU-compatible version of\r
79 "install" in the default $PATH.\r
80 \r
81 Blake\r
82 \r
83 [1] http://www.oracle.com/technetwork/systems/end-of-notices/eonsolaris11-392732.html\r
84 [2] Caveat: I work for Oracle in the Solaris kernel group, but I am not\r
85     speaking for my employer.\r