Hi, 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: http://master.debian.org/~jim/snapshot/ 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. Some examples: Gnome / Gtk / Gimp KDE GNU libc Linux kernel egcs GNUstep Mozilla Gnus 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 conflicts. No packages in the regular Debian distribution should depend upon the snapshot packages, although snapshot packages can certainly depend upon regular packages. News ---- Dec. 15, 1998 * This web page was created. Mailing List ------------ Send a message containing the word "subscribe" in the body to [EMAIL PROTECTED] in order to sign up. There currently is no list archive, but that will be rectified shortly. Participants ------------ Jim Pick <[EMAIL PROTECTED]> - Web page - Packages: orbit, gnome-libs, gnome-core, gnome-guile, gnome-objc, gnome-utils, gnome-media Please contact [EMAIL PROTECTED] to be added to this list. Issues ------ There are many issues to address, such as: * Facilities 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 multi-architecture snapshots. * 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. * Dependencies 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. * Trust 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 ones. * 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 bandwidth hog. 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 a project. 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. Cheers, - Jim