From: Suvayu Ali <fatkasuvayu+linux@gmail.com>
To: notmuch@notmuchmail.org
Subject: Re: Submodules for language bindings (was: Github?)
Date: Fri, 9 May 2014 13:39:51 +0200 [thread overview]
Message-ID: <20140509113951.GD2634@chitra.no-ip.org> (raw)
In-Reply-To: <20140508233530.GV28634@odin.tremily.us>
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.
next prev parent reply other threads:[~2014-05-09 11:40 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-08 5:28 Github? Wael Nasreddine
2014-05-08 5:30 ` Github? Wael Nasreddine
2014-05-08 7:23 ` Github? Jani Nikula
2014-05-08 7:13 ` Github? Jani Nikula
2014-05-08 8:40 ` Github? Eric
2014-05-08 10:13 ` Github? Guyzmo
2014-05-08 19:54 ` Github? Wael Nasreddine
2014-05-08 20:14 ` Github? Wael M. Nasreddine
2014-05-08 20:23 ` Github? Felipe Contreras
2014-05-08 20:30 ` Github? Suvayu Ali
2014-05-08 21:21 ` Github? guyzmo
2014-05-08 22:00 ` Github? Suvayu Ali
2014-05-08 22:29 ` Submodules for language bindings (was: Github?) W. Trevor King
2014-05-08 22:45 ` Suvayu Ali
2014-05-08 23:35 ` W. Trevor King
2014-05-09 11:39 ` Suvayu Ali [this message]
2014-05-09 12:40 ` Felipe Contreras
2014-05-09 12:50 ` Suvayu Ali
2014-05-09 13:09 ` Felipe Contreras
2014-05-09 2:45 ` Github? Felipe Contreras
2014-05-08 20:23 ` Github? W. Trevor King
2014-05-08 22:39 ` Github? David Bremner
2014-05-08 23:18 ` Github? Wael Nasreddine
2014-05-08 23:49 ` Github? W. Trevor King
2014-05-09 0:13 ` Github? Wael Nasreddine
2014-05-09 2:28 ` Github? W. Trevor King
2014-05-09 2:44 ` Github? Felipe Contreras
2014-05-09 2:43 ` Github? Felipe Contreras
2014-05-09 2:56 ` Github? Wael Nasreddine
2014-05-09 2:54 ` Github? Felipe Contreras
2014-05-09 3:01 ` Github? W. Trevor King
2014-05-09 3:08 ` Github? Felipe Contreras
2014-05-09 3:08 ` Github? Douglas Campos
2014-05-09 2:31 ` Github? Felipe Contreras
2014-05-08 23:30 ` Github? David Bremner
2014-05-09 12:13 ` Github? Amadeusz Żołnowski
2014-05-09 12:37 ` Github? Felipe Contreras
2014-05-10 1:21 ` Github? David Bremner
2014-05-10 5:08 ` Github? Wael M. Nasreddine
2014-05-10 7:49 ` Github? Tomi Ollila
2014-05-10 8:22 ` Github? Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140509113951.GD2634@chitra.no-ip.org \
--to=fatkasuvayu+linux@gmail.com \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).