ANNOUNCE: Debian Snapshot Project webpage
A new Gnome beta release is fast approaching, so I'm starting to work
on developing CVS snapshot packages again while I'm waiting for some
official tarballs to be released.
A lot of people have expressed interest in helping out with building a
Gnome snapshot system. I'd hate to waste all that enthusiasm, but
it's a big job, which would require some organization. There are a
lot of issues to address. I'd like to build a system which was
generic enough that it could be used for other projects beyond Gnome.
I've summarized most of my ideas, and put them on a web page:
I'll repeat the content here so I can get some feedback:
-- cut here --
Debian Snapshot Project
The Debian Snapshot Project (DSP) is an effort to develop a
comprehensive system for automatically compiling packages from CVS
repositories and snapshot releases.
In the free software community, there are a number of very active
software development projects which rely upon CVS repositories or
regular, rapid snapshot releases for their development branches.
Gnome / Gtk / Gimp
These projects all make regular stable releases, which are already
packaged as part of Debian GNU/Linux.
However, in many cases, developers that use Debian would like to have
the latest development releases available in .deb format so that they
can easily stay on top of the development cycles without having to
labouriously compile from snapshots or CVS.
These development packages are difficult to incorporate into the
regular Debian release, as they tend to have unstable APIs which will
regularily break packages which depend upon them.
The snapshot packages created by this project will be packaged in such
a way that it will be possible to have them installed at the same time
as the packages in the regular Debian distribution without causing any
No packages in the regular Debian distribution should depend upon the
snapshot packages, although snapshot packages can certainly depend
upon regular packages.
Dec. 15, 1998 * This web page was created.
Send a message containing the word "subscribe" in the body to
email@example.com in order to sign up.
There currently is no list archive, but that will be rectified
Jim Pick <firstname.lastname@example.org>
- Web page
- Packages: orbit, gnome-libs, gnome-core, gnome-guile, gnome-objc,
Please contact email@example.com to be added to this list.
There are many issues to address, such as:
Making regular snapshots (ie. daily) of these packages will take
a lot of computing horsepower. It would be nice to have a
distributed build system for compiling them. We could also do
* Build Intervals
The snapshots could be built daily, weekly, or even monthly, or
on a manual schedule. It seems likely that different packages may
be built on different schedules.
Many snapshot packages have source dependencies on other snapshot
packages. eg. gnome-core needs gnome-libs which needs gtk, glib,
and imlib (usually, all out of the CVS).
Source dependencies may depend on other packages that are built
the same day. ie. In order to build gnome-libs, it may be
necessary to build gtk first, and install it.
* Build Failures
With an automated compilation system, there are going to be days
when upstream bugs prevent the compilation of a particular
package. This may vary by architecture.
It gets messy with source dependencies. In some cases, it might
be possible to use a source dependency from a previous snapshot
in order to get things to work. This type of failure is very
common with development snapshots, because the APIs are
constantly in flux.
Maintainers don't have enough time to babysit the build process
everyday. It would be nice to have some sort of centralized
system (ie. a CVS repository) so that other maintainers could
make bug fixes using a team approach.
If a bug is fixed on a certain day, it would be nice to be able
to restart the build process. As a result, their could
conceivably be multiple builds per day.
* Bug Reporting
We should have a system in place for forwarding bugs and fixes we
discover to the upstream authors.
If we build snapshots daily, and automatically install them, this
introduces the security issue that the upstream sources can
introduce trojans and gain root access to the auto-compilation
(or end users) machines.
* Packaging Rules
There are many ways of modifying the Debian package build process
to accomodate automated builds. If we could develop some
standardized ways of doing things, it would be nice.
* Policy Differences
There are many areas where packages built as snapshots would
deviate from standard Debian policies. For example, we may
configure our snapshot packages to install under /opt instead of
the regular FSSTND directories. We would do that in order to
avoid conflicting with the regular Debian packages. We might also
compile using -rpath, so that the snapshot packages will link
with specific snapshot libraries, rather than the standard Debian
* Mirroring Network
A regular snapshot system will create significant load on the
mirroring system. For example, glibc could be rebuilt daily. That
would result in 26 MB of new .deb files every day. Because users
can update daily (ie. using apt-get), it could be quite a
Many people have discussed developing a differential mirroring
system specifically for Debian packages. Day-to-day, most files
inside the .debs will remain the same, so a differential
mirroring system would only transfer the differences.
-- cut here --
As you can see, this is a bit ambitious. It's definitely much more
than a single person could do - that's why I'm trying to set it up as
If we were organized enough, I don't see why we couldn't do it. If we
could make this work, I think that it would really set Debian apart as
the best Linux distribution for free software development.