Re: [Administrivia] On ruby and contrib/

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Jun 6, 2013, 21:05 UTC
Message-ID: <CALkWK0kQSuvv9owUYxatKTKW+GEpR0kL6XsyrOJD66yfodycUQ@mail.gmail.com>
In-Reply-To: <rmisj0vnorm.fsf@fnord.ir.bbn.com>

Greg Troxel wrote:

> It's not about what I want.  It's about making choices that affect other
> people, and trying to find a plan that will be overall reasonable;
> that's the essence of stewardship in packaging.  Compiling for just
> myself is far easier.

Have you asked the SBCL or Google-Chrome package maintainers what they have to deal with? I believe they're packaging nightmares. GHC/ Haskell projects aren't far behind. Git is probably the _last_ thing to be complaining about when it comes to packaging.

Sure, people want to run Git on embedded devices like Rpi. The core is already in C and Bourne Shell, and I don't see anyone rewriting that in Ruby. No cause for concern.

Show 12 quoted lines

> That ignores the 99% of people who use packaged versions.  The question
> is really "Should the standared approach for building be to use or not
> use dependency X?".  Really this should be expressed in the README, and
> it creates expectations for someone who just installs the git package in
> terms of whether pieces of functionality are there.  Packagers generally
> should be reading the README and including required/recommended
> dependencies and not including optional dependencies (in the main
> package).  The information in INSTALL is pretty reasonable, but it
> doesn't really clearly say "if you hand someone git built without perl,
> it is { perfectly ok but missing a fringe optional feature | deficient
> because "git add -p" won't work }.   I'm leaning towards the "deficient"
> camp.

So whom is this extra dependency affecting, if 99% of users are using packaged versions? So, it's just extra burden for the package maintainers (and users on source-based distributions)? git-svn and git-send-email are already separate packages on Ubuntu/Debian because they depend on lots of CPAN packages that can be non-trivial to install for new users. If we do get one important Ruby script, ship it as a separate package: done?

At the moment, there's just contrib/git-related that depends on ruby. Can we just stop planning centuries in advance, and tackle the problem when it arises? It remains to be determined whether or not git.git will grow a healthy ruby sub-ecosystem. If it does, package maintainers will be inconvenienced slightly. Otherwise, we'll just throw out the ruby code that's rotting in our tree, and get on with our lives.

The direction of the project is not decided on the basis of some vague future packaging expectations. It's decided on the basis of what patches come in from contributors, and everything else is secondary. If people want to write ruby, they will write ruby. Whether or not the git project welcomes their contributions.