On Thu, Feb 13, 2003 at 09:34:18PM +0000, Jonathan McDowell wrote: > I'm sure I've seen this hashed over in the past, so feel free to point me > at list archives. > > I'm the Debian maintainer for pksd, an OpenPGP keyserver. I've been asked > by upstream if I want to maintain the debian/ directory in the project's > CVS. The RPM .spec file is already done this way. Is there any good reason > not to do this? It will make things a lot easier for people pulling > running CVS builds. The only drawback I can see is changes in the > packaging between releases leads to a whole new src tarball to upload to > the archive rather than just a new diff, but hopefully this shouldn't > happen too often.
Here is my list of stock answers to this question. Some of the problems go away if you ensure that: - The debian/ directory is not shipped as part of upstream tarball releases, and - The debian/ directory is not included in normal CVS checkouts Both of these can be accomplished by creating a separate branch for the Debian packaging, but this is often undesirable. -- - mdz
- 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. Speaking from personal experience, I can say that this is often untrue. 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.
