Message-Id: <m0wRYca-0003DZC@sweat.cs.unm.edu>
Date: Wed, 14 May 1997 01:37:12 -0600 (MDT)
From: Barak Pearlmutter <bap@cs.unm.edu>
To: submit@bugs.debian.org
Subject: dselect feature req (not user interface!)

Package: dpkg
Version: 1.4.0.8

When using the ftp method to access a repository, often the Packages
files do not quite match the .deb files in the distribution.  Almost
always this is due to version skew, and some .deb files have slightly
higher version numbers than the corresponding entries in the Packages
file.  When attempting to INSTALL, error like

 getting: big-long-dir/pack_vera-verb.deb (xxx)
 big-long-dir/pack_vera-verb.deb: No such file OR directory.

This is a very very common problem, so basically the loop for
upgrading a debian box by ftp is usually:

 Update
 Select
 Install
 (manually record bad files)
 (manually fetch new versions)
 (manually install new versions)
 (manually delete those that installed successfully)
 Quit

(The reason this doesn't get you into trouble is that dpkg won't let
you hurt yourself due to dependency problems.  Bravo dpkg.)

People have complained about this, and proposed various mechanisms for
ensuring that the Packages files stay more consistent with the actual
packages available.  But given network reliability & mirroring
software, this problem cannot be fixed entirely.

How about if, instead, dselect and dpkg-ftp automated the above manual
process: it is easy enough to notice the missing file and instead of
just reporting it, get a DIR looking for newer versions in the
appropriate directory, and present the user with a message like:

 can find: big-long-dir/pack_vera-verb.deb, but pack_(vera+1)-1.deb is
 available.  Should I try to use that instead?

And if this results in dependency problems later, well so be it.
(Maybe there should be a chance for the user to resolve dependency
problems after the fetch but before actual install, when the new
control files are actually available.  Or maybe not, if that would be
a hassle to hack up.)