65/3111c4b1ec48a884387739020d18d3879ba406

   1 Return-Path: <fatkasuvayu+linux@gmail.com>\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 D39B5431FBF\r
   6         for <notmuch@notmuchmail.org>; Fri,  9 May 2014 04:40:03 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.799\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
  13         FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id 8EtMZsMQkPyQ for <notmuch@notmuchmail.org>;\r
  17         Fri,  9 May 2014 04:39:59 -0700 (PDT)\r
  18 Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com\r
  19  [74.125.83.42])        (using TLSv1 with cipher RC4-SHA (128/128 bits))        (No client\r
  20  certificate requested) by olra.theworths.org (Postfix) with ESMTPS id\r
  21  DC29D431FBC    for <notmuch@notmuchmail.org>; Fri,  9 May 2014 04:39:58 -0700\r
  22  (PDT)\r
  23 Received: by mail-ee0-f42.google.com with SMTP id d49so2612405eek.29\r
  24         for <notmuch@notmuchmail.org>; Fri, 09 May 2014 04:39:56 -0700 (PDT)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;\r
  26         h=sender:date:from:to:subject:message-id:mail-followup-to:references\r
  27         :mime-version:content-type:content-disposition\r
  28         :content-transfer-encoding:in-reply-to:user-agent;\r
  29         bh=l0Gr4PjcqIANtJ4FzXyT8kyGEPj74ohrIzwm1qCyEdQ=;\r
  30         b=zIMOIKfW2SW+au+CoVYfkJQL9J+kGUiJRfuOd+Iy3szJDMFzPWVfgy2i6LPnkL3dKj\r
  31         ELpw9pjbmHtyJtobSYWNVGX/UXbpKS3HKGuRcEwA/Ivfm5d8OWJ5NbYu5eNVGJs4BqOG\r
  32         EYhTisfhcLl4fFZWNqVMyHnO9HExzW6202ru9qStnvETgvSxpBDfgwTeLgKLTFsAqiV2\r
  33         Hll7Ma+MtlPT3dU/e8bbCKQUAAB67PZPa0cRR2/LGCPvSHM0OTZQCoc+8ChF37APwo8L\r
  34         qWoFyFx8fmDmrkbA1dk+CtOxw+0qbMu7jX+hKuIJw7zXaGJeA4qJ5ORkxme5d/lJ33ng\r
  35         aJeg==\r
  36 X-Received: by 10.14.115.195 with SMTP id e43mr12870970eeh.76.1399635596087;\r
  37         Fri, 09 May 2014 04:39:56 -0700 (PDT)\r
  38 Received: from chitra.no-ip.org ([2001:610:120:3001:2ad2:44ff:fe4a:b029])\r
  39         by mx.google.com with ESMTPSA id u46sm10872267eel.1.2014.05.09.04.39.52\r
  40         for <notmuch@notmuchmail.org>\r
  41         (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\r
  42         Fri, 09 May 2014 04:39:53 -0700 (PDT)\r
  43 Sender: Suvayu Ali <fatkasuvayu@gmail.com>\r
  44 Date: Fri, 9 May 2014 13:39:51 +0200\r
  45 From: Suvayu Ali <fatkasuvayu+linux@gmail.com>\r
  46 To: notmuch@notmuchmail.org\r
  47 Subject: Re: Submodules for language bindings (was: Github?)\r
  48 Message-ID: <20140509113951.GD2634@chitra.no-ip.org>\r
  49 Mail-Followup-To: notmuch@notmuchmail.org\r
  50 References: <E1WiJsj-0004mz-VK@teckel.deptj.eu>\r
  51         <20140508101325.GC23124@vilya.m0g.net>\r
  52         <CA+kKtKA8Q5z6Pys9RAumLTiJvmGwWYKGXDkKr9Mh_6ecV-7sdA@mail.gmail.com>\r
  53         <CA+kKtKCP8Oo2sHz5Cd0+=BmS9UK=b2h9GrGopUFwWZ=GJUXqyA@mail.gmail.com>\r
  54         <20140508203019.GA2374@chitra.no-ip.org>\r
  55         <20140508212100.GD23124@vilya.m0g.net>\r
  56         <20140508220046.GB2374@chitra.no-ip.org>\r
  57         <20140508222931.GU28634@odin.tremily.us>\r
  58         <20140508224527.GC2374@chitra.no-ip.org>\r
  59         <20140508233530.GV28634@odin.tremily.us>\r
  60 MIME-Version: 1.0\r
  61 Content-Type: text/plain; charset=utf-8\r
  62 Content-Disposition: inline\r
  63 Content-Transfer-Encoding: 8bit\r
  64 In-Reply-To: <20140508233530.GV28634@odin.tremily.us>\r
  65 User-Agent: Mutt/1.5.22.1 (2013-10-16)\r
  66 X-BeenThere: notmuch@notmuchmail.org\r
  67 X-Mailman-Version: 2.1.13\r
  68 Precedence: list\r
  69 List-Id: "Use and development of the notmuch mail system."\r
  70         <notmuch.notmuchmail.org>\r
  71 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  72         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  73 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  74 List-Post: <mailto:notmuch@notmuchmail.org>\r
  75 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  76 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  77         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  78 X-List-Received-Date: Fri, 09 May 2014 11:40:04 -0000\r
  79 \r
  80 Hi Trevor,\r
  81 \r
  82 On Thu, May 08, 2014 at 04:35:30PM -0700, W. Trevor King wrote:\r
  83 > On Fri, May 09, 2014 at 12:45:27AM +0200, Suvayu Ali wrote:\r
  84 > > On Thu, May 08, 2014 at 03:29:31PM -0700, W. Trevor King wrote:\r
  85 > > > On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote:\r
  86 > > > > One of my TODOs is to also package the ruby bindings, and\r
  87 > > > > notmuch-vim.  The only thing preventing me now is my\r
  88 > > > > unfamiliarty with ruby, and Fedora packaging guidelines for\r
  89 > > > > ruby-gems.\r
  90 > > > \r
  91 > > > I think this is one argument argument in favor of submodules,\r
  92 > > > because they make it easy to treat the bindings as separate\r
  93 > > > packages.  Once you have separate packages, it's easy to delegate\r
  94 > > > packaging (e.g. “I don't use the Ruby bindings, so I'm not going\r
  95 > > > to maintain the Ruby-binding package.  I'll leave that to Alice,\r
  96 > > > who likes Ruby, but is less familiar with $distro's Python\r
  97 > > > packaging”).\r
  98 > > \r
  99 > > Well as far as my understanding of rpm goes, sub-packages are\r
 100 > > prefered here rather than independent packages.  I believe the\r
 101 > > reason is again easier dependency tracking[1]; all sub-packages\r
 102 > > share the same source rpm, so no explicit `Requires' in the spec\r
 103 > > file.\r
 104 > \r
 105 > It looks like sub-packages share a single spec file with the main\r
 106 > package [1].  That means you'll have to have authors with the full\r
 107 > range of binding-language expertise to bump that spec file (assuming\r
 108 > there are any changes that require bumps).  For example, Gentoo's\r
 109 > Python eclasses have gone through a few revisions in the last year or\r
 110 > two, and I wouldn't expect one person to stay on top of the latest\r
 111 > packaging styles for every language with notmuch bindings.  I think\r
 112 > the benefit of having separate packages (and spec files, or ebuilds,\r
 113 > or whatever) is that you can release notmuch-0.18 without worrying\r
 114 > about all those bindings, and leave it to the other maintainers (who\r
 115 > might include you) to independently package notmuch-python-0.18,\r
 116 > notmuch-ruby-0.18, notmuch-go-0.18, ….  With only three sets of\r
 117 > bindings, it doesn't really matter, but I think you'll want the weaker\r
 118 > coupling of stand-alone packages by the time you hit a dozen\r
 119 > languages.  “Bump an explicit 'Requires'” certainly seems like a lower\r
 120 > barrier than “package Go bindings idiomatically for Fedora” ;).\r
 121 \r
 122 You have a point, however I would still disagree.  You seem to use\r
 123 Gentoo, and I think what you say works better for Gentoo because it is a\r
 124 source distribution.  For binary distributions, this is a bit harder\r
 125 (and limiting).  To explain my point with RPM specifics, if I were to\r
 126 use separate spec files, python-notmuch would have:\r
 127 \r
 128   Requires: notmuch >= <version-string>\r
 129 \r
 130 As you can see this only allows for tracking dependency based on\r
 131 official version numbers.  With more bindings, many with different\r
 132 version dependencies, this becomes quite cumbersome; more so when you\r
 133 are doing snapshots (as I do for my repo[1]).  As a packager, I think I\r
 134 would prefer to learn different packaging guidelines, setup my spec file\r
 135 and forget about it rather than continually follow all changes.  But I\r
 136 guess this is where you would argue with different responsible people, I\r
 137 would not have to do all the thinking :-p.\r
 138 \r
 139 Anyway, whichever way the devs choose to go, I (and other packagers)\r
 140 will adapt.\r
 141 \r
 142 Cheers,\r
 143 \r
 144 \r
 145 Footnotes:\r
 146 \r
 147 [1] I would love to know if anyone here uses it.  I announced it here\r
 148     when I started it, but for all I know I could be the only user!  :-p\r
 149 \r
 150 -- \r
 151 Suvayu\r
 152 \r
 153 Open source is the future. It sets us free.\r