[mythtv] Building CVS debs? (not for distribution)

[Matt Zimmerman]

On Fri, Jul 11, 2003 at 02:02:03PM -0500, Geoffrey Hausheer wrote:

> On a similar note, I'm pretty sure Matt has a good reason for not
> including the /debian sub-directory in CVS (so we could all build CVS
> from source and still use apt), but I don't know what it is.  Can anyone
> enlighten me?

Here is my stock response to the idea of keeping debian packaging metadata
together with the upstream source.

-- 
 - mdz
-------------- next part --------------
- The Debian development cycle is mostly orthogonal to the upstream development
  cycle.  Usually, several releases of a Debian package will be made for a
  single upstream release.  If the Debian packaging information is shipped with
  the upstream source, it will either be continually out of date (and perhaps
  even broken), or new releases will have to be made with no substantial
  changes for non-Debian users.

- For the same reason, the Debian maintainer would have to have write access to
  the upstream CVS repository.  This is often otherwise unnecessary or 
  undesirable.

- Debian tools make it very easy for the user to build their own .debs from
  source.  In fact, they don't even need to locate and download the upstream
  source, as this is managed by the Debian packaging system and archive mirror
  network.  For example, a simple recompile (taking into account, say, a local
  CFLAGS or DEB_BUILD_OPTIONS environment variable) can be done with a single
  command:

  apt-get source -b <package>

  Building a version with more extensive modifications is almost as easy:

  apt-get source <package>
  cd <package>-<version>
  # Edit source files, change configuration, etc.
  dpkg-buildpackage

- Debian source packages essentially consist of a copy of the upstream source
  tarball (intact, when possible, so that signature verification and the like
  can be performed) and a compressed diff which includes any debian-specific
  changes.  This makes it easy for the user to recognize what changes were made
  to the source code for the Debian package, and allows the user to selectively
  add or omit such changes.

- Debian packages should always have a sane and meaningful version number.
  This is problematic if a (static) debian/ directory is included in an
  upstream CVS repository, and dynamically generating a version number and
  changelog has its own problems.

For example, the flac package, which has gone through 6 fast-paced upstream
releases (0.5 through 0.10), two of these (0.5 and 0.6) have involved more than
one Debian revision (0.5-2 and 0.6-2).  If the debian/ directory had been
included in CVS and released with flac, its contents would have been out of
date almost immediately.  Consider the following (very common) sequence of
events:

1. New upstream release is made
2. Further changes are made in upstream CVS to work toward next release
3. Debian-specific changes are required (to meet policy compliance, or because
   of unforeseen integration issues with other Debian packages)

These changes could be made in upstream CVS and in the Debian diff against the
previous release, but users building Debian packages from the latest upstream
sources would get an out-of-date (and possibly very broken) Debian package.  So
truly, the only people who could make use of the upstream debian/ directory are
those who are building Debian packages from CVS.  The debian/ directory
included with official releases would always be out of date, and possibly
broken.