As one of the people who helps maintain git packages in pkgsrc, my initial reaction is negative to adding a ruby dependency. There are several not-entirely-related reasons: git is a core tool that people use on almost the smallest of boxes, perhaps even replacing rcs for managing local config files. On such machines, even perl may be large, but a second scripting language seems excessive. On a NetBSD 6 i386 system, the size of the ruby193-base binary package (as installed) is 25 MB (vs 15 MB for the git base package, which lacks gitk and docs). (Presently, the git base package defaults to requiring python and installing the git_remote_helpers, but I think that's a bug.) perl is 54 MB. I am unclear on how mature/stable ruby is. perl has a good track record over the last many years. In particular, no one in pkgsrc has felt the need to support multiple concurrent versions of perl. But there presently exists both 1.8 and 1.9 in pkgsrc (and there are multiple python verions). So given how critical git is on many systems, I'd ask if the ruby requirement is for a stable vs old vs bleeding-edge version, and how that is expected to function over the next 5 years. (With perl, the answer seems to be "any half-way modern version of 5.x is fine, from unreasonably old to the latest release".) By stable, I don't mean that a particular ruby release works well. I mean the experience of having code that depends on ruby over many years, and whether one can just use whatever ruby happens to be there, or whether it's effort to manage having an acceptable version. From a packaging viewpoint, dependencies are costly, because they force build and installation of them before the package can be built. In a source-centric packaging environment (where it's normal to build, rather than only having pre-built packages), the question is if the git package needs ruby, which is a different question than whether something in git which may be optional needs ruby. So if ruby, or something else, is needed for optional components, it would be really nice if the build system were such that it was simple (via arguments to configure, selecting subdirs, or something functionally similar) to build the main part, and then the ruby part as a separate build. Then, it would be pretty easy to have git-ruby package that has the ruby parts. But if the ruby part isn't considered optional, that won't work. (Note that the usual GNU/Linux approach of split binary packages doesn't really address this, because as I understand it you need the union of the dependencies installed to build once, and then tar up the resulting bits separately. So that fixes the problem for people that install binaries, but doesn't help building from source.) tcl/tk is another dependency, but it seems limited to gitk. pkgsrc has a separate scmgit-gitk package, which is relatively easy to maintain because it just involves selecting subdirs to build. So that's an example of a good way to do it, from the source-based packaging viewpoint. Finally, I realize that most people on this list will build git directly From sources. While that of course has to be smooth, I think great weight should be given to how packaging systems use releases and how that impacts packaging effort and the eventual user experience. I would guess that over 99% of git users are running binaries built from a packaging system.
Attachment:
pgpcy1xSlaj46.pgp
Description: PGP signature