The aim of the
vcs-pkg project is to investigate the use of version control for distro package maintenance. We bring together people interested in
taking the next step in distro package maintenance: the proper integration of version control into the package maintenance workflow.
This effort originated in the bowels of the Debian project, but it's not specific to Debian. The cross-distro aspect of
vcs-pkg is its most powerful aspect.
Maintainers of a specific package in all distros basically have the same task. We could benefit from each other if we joined forces: less workload, improved access to patches in use by other distros, more structured communication, a wider spread of innovation, etc..
A lot of Debian is already using version control for the task, but everyone cooked up something of their own, more or less. We think the situation is similar in the other distros: the current approach to package maintenance doesn't scale too well, given today's needs (teams, offline work, increasing number of users and increased use of the bug trackers), and discussions of how to improve things are on the way, but have not yet carried fruit.
Why not approach the challenge together?
Our goal is to integrate version control with distro package maintenance. We want to recognise all involved in the process, from upstream, the package maintainers of the various distributions, their security and release teams, and power users, who aren't afraid to fix their own bugs, and give maximum flexibility to them.
vcs-pkg is (D)VCS-agnostic, and it'd be ideal if it stayed that way. However, part of what we do is comparing version control systems and assessing their merits, and one tool may outperform the others. We want to avoid the religious wars of version control and instead argue technically and sensibly about their individual advantages and shortcomings in the context of distro package maintenance. A desired output could be a VCS-agnostic wrapper of the concepts involved in maintaining and developing a distro package of an existing software.
- mailing list (archived and also on gmane)
- vcs-pkg people
- planet (blog aggregator)
- IRC channel:
- list receiving commit messages
- Browse this web site's Git repository (clone links are to be found there)
- features of different vcs-pkg systems
- Thoughts on consolidating packaging workflows across distros
- Reasons for pushing patches upstream
- LWN.net coverage of Jeff's "Disintermediating Distributions" talk at LCA 2008
- pristine-tar, a tool to make it possible to store/extract pristine (original) tarballs in/from a Git repository (blog post).
- bzr-loom, a
bzr-plugin to work with multiple patches/branches at once (HOWTO, discussion).
- TopGit, a tool to manage patch queues with inter-patch dependencies (announcement, README, Debian package, description of Debian packaging approach)
- git-hierarchy, manage branch dependencies (a TopGit alternative?)
- Conary and a discussion of how it relates to vcs-pkg. Another discussion on #conary
- Project-Builder, a tool to create packages from an upstream VCS (CVS,SVN, GIT, Mercurial at the moment) or upstream tar files for multiple OSes (Fedora/RHEL, Mandriva, OpenSUSE/SLES, Debian/Ubuntu, Gentoo, Solaris/OpenSolaris) using Virtual QEMU machines or Virtual Environments with rinse/pbuilder/mock using configuration file managed in a VCS. It provides the feature of Continuous Packaging.
- gear Set of tools to manage src.rpm in git repositories.
- distributions@freedesktop (see this post about how it's related to
- desktop_architects@linux-foundation, although that's only marginally related.
- Distributed bug tracking systems, a sister site dedicated to to investigating and developing distributed bug tracking systems.
Links are arranged in chronological order for the most part, so often the ones further down are more "contemporary" and might be closer to the current best-practice, as far as there is one.
Source packages and VCS:
- Suggestion how to use VCS to replace package uploads in Debian
- How Ubuntu wants to get/has gotten rid of source packages and their previous approach, which is not entirely obsolete yet.
- Joey Hess' evolutionary source package format based on Git
- The W&P specification (outdated) and latest status
- "dpkg-source's future and relation with VCS" thread on firstname.lastname@example.org
- (massive) thread on the handling of patches in response to the OpenSSL fiasco, and lwn.net coverage. Thanks, Jonathan!
- madduck's Git-based packaging workflow described and an offer for an online tutorial
- How to convert an SVN-maintained package to madduck's Git workflow
- Cate's brainstorm on how to use Git for Debian packaging
- madduck's LCA 2008 presentation of his workflow: slides, video
- Pierre's FOSDEM 2008 presentation of his workflow: slides, video
- madduck's DebConf8 presentation of a TopGit-using workflow: slides, video
- Manoj's Work-flow, in a nice activity diagram format: blog post
- Discussion thread on Mehdi's/Stéphane's simpler-than-TopGit quilt-based workflow
- A gitpkg+quilt workflow proposed by David Bremner
- debcheckout, a tool to obtain the sources from VCS for any Debian package, manpage, introductory blog post, and blog post about new features
- unperish (homepage), a tool for building, testing, and publishing a software release
- git-buildpackage and a bit of a how-to use it, as well as its manual
- darcs-buildpackage and a bit of a how-to use it
- hg-buildpackage (which has been orphaned)
Fedora / RedHat
- Doug Ledford's homepage, with thoughts on using VCS as an alternative to SRPMs
- Plague, Fedora's distributed package build system
- How Fedora want to use VCS for packaging and their architecture draft
- How to use VCS for packaging in Fedora FAQ
- cvs exporter for producing generic srpm's from VCS repositories
- Documentation for OpenSuse's Build Service
- Three videos from FOSDEM 2009 explaining different aspects of the service: overview, collaboration, and cross-building
- Arch has been using CVS to track their PKGBUILDs from the start, and has been using Subversion instead for some time.
- HOWTO for Arch developers and trusted users
- GIT for the devtools used by developers and trusted users to ease workflow
- GIT for the dbtools code used on the server that manages the repository
- Link to the viewvc interface for offical packages and community/trusted user packages