Version Control System (VCS) sources

Rather than working with a source tarball, it is possible to use upstream source code repositories directly. This can be useful when there is a need to test unreleased snapshots on a regular basis. A number of eclasses exists for this purpose; see their documentation for a list of available functions and variables.

Disadvantages of VCS sources

Note that VCS ebuilds should not generally be added to the tree for the following reasons:

  • Upstream VCS servers tend to be far less reliable than our mirroring system.
  • VCS ebuilds create a very heavy server load — not only are repositories not mirrored, but fetching sources from them is considerably more work for a server than simply serving up a file via HTTP or FTP.
  • Local copies of a repository are several times larger than a tarball of the same sources, and tend to grow over time because they include the history.
  • Many users who are behind strict firewalls cannot use protocols like CVS.

It is safer (and better for the user) to make a snapshot instead. For example, app-editors/emacs snapshots are made using:

$ git archive --prefix=emacs/ HEAD | xz > emacs-${PV}.tar.xz

Disadvantages of VCS live sources

VCS ebuilds that work against the latest head (or tip) rather than a specific date or revision are even worse candidates for tree inclusion:

  • You can never be sure whether upstream's source will actually build at any given point; which will most likely cause QA issues.
  • It is extremely difficult to track down bugs when you cannot install the same version of a package as the reporter.
  • Many upstream package maintainers tend to get upset if people aren't using a specific released version.