Sender: Suvayu Ali <fatkasuvayu@gmail.com>
Date: Fri, 9 May 2014 13:39:51 +0200
From: Suvayu Ali <fatkasuvayu+linux@gmail.com>
To: notmuch@notmuchmail.org
Subject: Re: Submodules for language bindings (was: Github?)
Message-ID: <20140509113951.GD2634@chitra.no-ip.org>
Mail-Followup-To: notmuch@notmuchmail.org
References: <E1WiJsj-0004mz-VK@teckel.deptj.eu>
	<20140508101325.GC23124@vilya.m0g.net>
	<CA+kKtKA8Q5z6Pys9RAumLTiJvmGwWYKGXDkKr9Mh_6ecV-7sdA@mail.gmail.com>
	<CA+kKtKCP8Oo2sHz5Cd0+=BmS9UK=b2h9GrGopUFwWZ=GJUXqyA@mail.gmail.com>
	<20140508203019.GA2374@chitra.no-ip.org>
	<20140508212100.GD23124@vilya.m0g.net>
	<20140508220046.GB2374@chitra.no-ip.org>
	<20140508222931.GU28634@odin.tremily.us>
	<20140508224527.GC2374@chitra.no-ip.org>
	<20140508233530.GV28634@odin.tremily.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20140508233530.GV28634@odin.tremily.us>
User-Agent: Mutt/1.5.22.1 (2013-10-16)
Precedence: list

Hi Trevor,

On Thu, May 08, 2014 at 04:35:30PM -0700, W. Trevor King wrote:
> On Fri, May 09, 2014 at 12:45:27AM +0200, Suvayu Ali wrote:
> > On Thu, May 08, 2014 at 03:29:31PM -0700, W. Trevor King wrote:
> > > On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote:
> > > > One of my TODOs is to also package the ruby bindings, and
> > > > notmuch-vim.  The only thing preventing me now is my
> > > > unfamiliarty with ruby, and Fedora packaging guidelines for
> > > > ruby-gems.
> > > 
> > > I think this is one argument argument in favor of submodules,
> > > because they make it easy to treat the bindings as separate
> > > packages.  Once you have separate packages, it's easy to delegate
> > > packaging (e.g. “I don't use the Ruby bindings, so I'm not going
> > > to maintain the Ruby-binding package.  I'll leave that to Alice,
> > > who likes Ruby, but is less familiar with $distro's Python
> > > packaging”).
> > 
> > Well as far as my understanding of rpm goes, sub-packages are
> > prefered here rather than independent packages.  I believe the
> > reason is again easier dependency tracking[1]; all sub-packages
> > share the same source rpm, so no explicit `Requires' in the spec
> > file.
> 
> It looks like sub-packages share a single spec file with the main
> package [1].  That means you'll have to have authors with the full
> range of binding-language expertise to bump that spec file (assuming
> there are any changes that require bumps).  For example, Gentoo's
> Python eclasses have gone through a few revisions in the last year or
> two, and I wouldn't expect one person to stay on top of the latest
> packaging styles for every language with notmuch bindings.  I think
> the benefit of having separate packages (and spec files, or ebuilds,
> or whatever) is that you can release notmuch-0.18 without worrying
> about all those bindings, and leave it to the other maintainers (who
> might include you) to independently package notmuch-python-0.18,
> notmuch-ruby-0.18, notmuch-go-0.18, ….  With only three sets of
> bindings, it doesn't really matter, but I think you'll want the weaker
> coupling of stand-alone packages by the time you hit a dozen
> languages.  “Bump an explicit 'Requires'” certainly seems like a lower
> barrier than “package Go bindings idiomatically for Fedora” ;).

You have a point, however I would still disagree.  You seem to use
Gentoo, and I think what you say works better for Gentoo because it is a
source distribution.  For binary distributions, this is a bit harder
(and limiting).  To explain my point with RPM specifics, if I were to
use separate spec files, python-notmuch would have:

  Requires: notmuch >= <version-string>

As you can see this only allows for tracking dependency based on
official version numbers.  With more bindings, many with different
version dependencies, this becomes quite cumbersome; more so when you
are doing snapshots (as I do for my repo[1]).  As a packager, I think I
would prefer to learn different packaging guidelines, setup my spec file
and forget about it rather than continually follow all changes.  But I
guess this is where you would argue with different responsible people, I
would not have to do all the thinking :-p.

Anyway, whichever way the devs choose to go, I (and other packagers)
will adapt.

Cheers,


Footnotes:

[1] I would love to know if anyone here uses it.  I announced it here
    when I started it, but for all I know I could be the only user!  :-p

-- 
Suvayu

Open source is the future. It sets us free.