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.
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html