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