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

Re: upgrading only urgency=high packages

On Tue, May 01, 2001 at 02:44:21PM -0400, Matt Zimmerman wrote:
> From: Matt Zimmerman <mdz@debian.org>
> To: debian-devel@lists.debian.org
> Subject: Re: upgrading only urgency=high packages
> Mail-Followup-To: debian-devel@lists.debian.org
> On Tue, May 01, 2001 at 02:12:24PM -0400, Dan Christensen wrote:
> > Is there a way to upgrade all currently installed packages which have
> > had an urgency=high version uploaded to the archive since I last
> > upgraded?  (And any necessary dependencies, of course.)  I'm thinking
> > of this for the unstable distribution.  The idea is to frequently do
> > such upgrades to get any security fixes, and less frequently do an
> > entire dist-upgrade.
> > 
> > (I know about testing, but for the machine in question I like to
> > stay current with unstable most of the time.)
> > 
> > I'm guessing that the information about the urgency fields might not
> > be available except in the changelog, so it might be necessary to
> > download the package and have a script look through the changelog.
> > 
> > Could apt-listchanges be hacked to do this?  Or could apt's new
> > pinning mechanism help?
> > 
> > Is urgency information stored anywhere besides the changelog?
> > How do the testing scripts do this?
> I had an idea (and a working script) to extract changelogs from source packages
> and insert them into a SQL database.  My original intention was to allow
> apt-listchanges to display changelogs for packages before downloading them, but
> such a database would also allow for queries like this.  It would also allow
> the CGI changelog viewer to work again.
> If the daily lintian runs start up again, this script could easily be run when
> a source package is unpacked, to keep the database up-to-date as new packages
> come into the archive.
You might look at another idea. When katie/dinstall runs it has to parse
the .changes file. This includes both the urgency info and the changelog
relevant to the current upload.

Gordon Sadler

Reply to: