To: debian-devel-announce@lists.debian.org
Subject: ANNOUNCE: Debian Snapshots Project webpage
From: Jim Pick <jim@jimpick.com>
Date: 16 Dec 1998 09:07:39 -0800


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/snapshots/

I'll repeat the content here so I can get some feedback:


-- cut here --


 Debian Snapshots Project
 ========================


The Debian Snapshots 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
debian-snapshots-request@lists.debian.org in order to sign up.

There currently is no list archive, but that will be rectified
shortly.


Participants
------------

     Jim Pick <jim@jimpick.com>

     - Web page
     - Packages: orbit, gnome-libs, gnome-core, gnome-guile, gnome-objc,
                 gnome-utils, gnome-media

Please contact jim@jimpick.com 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


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org