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. _______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch