[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to handle updates to bo?

Dale has asked me to forward this to debian-devel to get a wider

------- Start of forwarded message -------
Date: Fri, 6 Jun 1997 07:24:41 -0400 (EDT)
From: Dale Scheetz <dwarf@polaris.net>
To: Guy Maor <maor@ece.utexas.edu>
cc: debian-qa@lists.debian.org, debian-testing@lists.debian.org,
Subject: Re: How to handle updates to bo?
Message-ID: <Pine.LNX.3.95.970606072110.26289E-100000@dwarf.polaris.net>

I like your solution. It involves a minimal amount of change to procedure
while putting adequate brakes and controles on the installation process.
This works for me.

On 5 Jun 1997, Guy Maor wrote:

> How does the testing group want to handle updates to bo?
> The current method of foo, foo-fixed, and foo-updates is a pain to
> administer and will be even more of a pain now that contrib and
> non-free are released.  I also do not think it has significant gains
> now that most people use dpkg-ftp to keep their system up to date.
> There will be many packages going to bo without going to hamm because
> I expect most developers will start migrating to libc6.  That nixes
> one solution of installing everything to unstable and moving packages
> from unstable to stable once they have been tested.
> The simplest solution (for me anyway) is to update bo now that it is
> called stable in a similiar fashion as was used when it was frozen:
> A developer produces a package earmarked for stable containing some
> important fix.  The developer will most likely be doing a special
> compile just for stable using the altdev packages.
> dinstall checks for gross package errors, such as an md5sum mismatch
> immediately, but does not install the package.  (it already does
> this.)
> Members of the testing group install the package out of Incoming.  I
> can easily arrange for debian-qa to receive an abbreviated copy of the
> install report that dinstall already sends to Brian and myself.  That
> report would contain relevant information about all the packages
> destined for stable that are currently in Incoming.
> The testing group decides the fate of the package and Brian invokes
> dinstall to install or reject it.
> If the package is installed, dinstall places it directly into the bo
> distribution and automatically updates the ChangeLog.  Once a day, the
> daily cron scripts update the Packages files.  If they see that new
> packages have been added to bo, they stamp the ChangeLog with the
> version number and update the top-level version symlink.
> New versions of bo are thus created as fast the testing group wants to
> create them.  An important security fix can be installed immediately
> forcing a version update.  Fixes of lesser important can wait in
> Incoming until enough of them are there to justify a new release.
> Comments, especially from Brian, please.
> Guy
------- End of forwarded message -------

I have since thought of one minor change.  Rather than actually
installing the package with dinstall, Brian can move it it to a
special incoming directory and dinstall can install it in its daily
run.  This will eliminate the too-common problem of the Packages file
not matching what is on the archive.


TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: