Why isn't Git used for package management?

Question

I've heard that Git has lots of advantages over subversion/CVS, especially speed so why do projects like FreeBSD continue to use CVS for the ports system? Wouldn't the distributed version control make it easier for new ports to be created and updated too? Also mercurial should be another good option and the same gos for all package management in all free operating systems.

Answer 1

Many other projects are using git (http://git-scm.com/): Linux Kernel, Perl, Ruby on Rails, WINE, Fedora, X.Org.

Answer 2

It is used. For example, see the Gentoo Overlays site.

Answer 3

If you mean using a DVCS for tracking the build scripts (port files, ebuilds, PKGBUILDs, rpm spec files, etc) then they are used. Fedora is probably the most popular distributions which partially uses Git. In this use case a DVCS isn't all that beneficial. You are generally online when updating packages (downloading new sources, etc), so the whole "offline committing" advantage doesn't really apply. In the end you have to use a central repository for others to contribute and have some sort of distribution model, so the distributed part isn't that beneficial either (you would rarely pull changes to your package from someone else). In general there aren't enough benefits of DVCSs for distributions to switch from traditional VCSs.

Edit: Archlinux was choosing between Subversion and Git not too long ago. They decided to go with Subversion, mostly because Git not provide any advantages, but also did not support partial checkouts. Support for this is coming though.

If you mean using the DVCS as a package manager itself, then I believe this has been done with at least one distribution. From what I remember the whole system is under version control. I do not know any details though.

Answer 4

A lot of it might have to do with inertia, a lot of projects have a bunch of infrastructure and process, like freebsd for instance, that depend on things being tied to CVS. This makes git a harder transition. Not to mention, there are certain things that git isn't as good at.

There is also the social reasons, some project's members, don't want to change.

Answer 5

Most package managers manage binaries, so you won't see the same performance gains as very little of the package would be 'diffable'. As Ben Collins mentioned, source-based package managers wouldn't face this problem.

Answer 6

See http://vcs-pkg.org/

Answer 7

For BSD ports and other projects like Drupal (also still on CVS), it largely because of inertia - the kind of software cruft inertia which piles up around a project after a while. You have a bunch of scripts which maintain the database, and you don't want to convert them all to a new VCS. You also have to remember that SVN is not that old in real-years terms - only 8 years old in total. Also, FreeBSD has apparently begun a transition to SVN (3 June 2008 entry).

In the non-ports-tree world of Debian, there are a lot of different VCS's being used for the packages. Most of them have a helper package in the form of -buildpackage. They are useful if your upstream is using the VCS or even if not. git-buildpackage has a really nice manual to get you started even.

As I've switched to moving to git for my packages, I've found that it's MUCH more useful because of the cheap branches and the easy three-way merging. It's very easy to triage bugs if you can branch for a bugfix and if you get interrupted you will not mess up a build of the package which will happen later.

Answer 8

Yet another reason is that having all versions in the history of the package manager would waste huge amounts of disk space, something you may have on your distribution and development servers, but not necessarily on production servers.

I, and presumably others, do use it for some low-volume projects, though the most important aspect in my case is tracking configuration files so I can see what my co-admins are doing, and the other is that no package management was in place so piggybacking git into the installation process was pretty easy. The volume of historical binaries may become a problem though.