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.

Note: VCS ebuilds must be with empty KEYWORDS but not package.masked (except if the mask is for an independent reason). Usually the KEYWORDS line should be omitted altogether. This applies to "live" ebuilds (-9999) and to ebuilds that extract a static revision but still use a version control system for fetching.

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.