Message-Id: <m0vnGPC-00001SC@turnbull.sk.tsukuba.ac.jp>
To: submit@bugs.debian.org
Subject: dselect and mirrors with incomplete archives
Date: Thu, 23 Jan 1997 13:04:50 +0900
From: "Stephen J. Turnbull" <turnbull@turnbull.sk.tsukuba.ac.jp>

Package: dpkg
Version: 1.4.0.6

I am using Debian 1.2, kernel version 2.0.27, and libc 5.4.13.

I observed the following problem of inconsistency between Packages and
the actual archive with a Debian mirror and reported it to the
mirrors.  Since I think it is a bug in the package management system,
I am reporting it here.  As I don't understand dpkg yet (I haven't
successfully installed the system, so don't really have access to docs
etc), I'm going to make some suggestions, but if they seem orthogonal
to common sense, they probably are.

I looked at titles to the bugs regarding dpkg, and didn't see anything 
related.  With my current bandwidth, actually reading all the reports
would take most of this week; sorry if I missed this one.

>>>>> At 11:44 AM 23/01/97 +0900, I wrote:

    me> I have been having a lot of problems with installation from the
    me> Debian Linux mirror at ftp.kreonet.re.kr.

    me> The basic cause seems to be that the package list was mirrored
    me> _before_ getting all the packages.  Thus many of the files are
    me> older than the version mentioned in the package list.  In
    me> particular, ftp.kreonet.re.kr claims to have libc_5.4.17-X.deb,
    me> but only has libc_5.4.13-X.deb.  Since many of the packages
    me> already updated depend on having at least libc 5.4.17, dselect
    me> goes crazy, and there are many errors in installation so dpkg
    me> can't recover.

    me> I suspect that this could be a problem at many overseas
    me> mirrors, as bandwidth really stinks recently.

>>>>> "Karl" == Karl Ferguson <karl@tower.net.au> responded:

    Karl> Unfortuantely we can't do much about that.  If files
    Karl> time-out enough when mirroring and mirror decided to spit
    Karl> the dummy and exit, then you'll end up having updated files
    Karl> all over the place.  It also depends on here the mirror is
    Karl> mirroring from.

    me> This really is a defect in the package management system.  As
    me> it is not possible to guarantee timely updates of a full
    me> mirror, the package list should be generated on the fly at the
    me> mirror.

    Karl> Bugs with mirrors should be reported directly to the mirror
    Karl> admins (as you see listed in the README.mirrors file) - it's
    Karl> not really the mirrors responsability to have thir own
    Karl> package maintenance system, if we demanded this then I doubt
    Karl> we'd have any mirrors left at all - I'm a mirror myself, and
    Karl> I wouldn't want that.

I agree with this; it seems to me that developing a script for
generating Packages rests with the dpkg maintenance team.  Since you
presumably already have one, it should be possible to modify it for
use by mirrors.  I recognize that this could potentially be annoying
because of various packages and versions of mirroring software, but
since dselect is the first thing us newbies see, you could chase all
of us back to RedHat and we wouldn't want that :-)

    Karl> Packages(.gz) etc are all updated and retrieved first during
    Karl> a mirror because it's first on the list.  As I said before,
    Karl> we can't help it if mirror spits the dummy and exits due to
    Karl> errors.

Right.  At a minimum, Packages ought to be the *last* thing on the
list, and *old* packages should not be purged (the Debian naming
system guarantees they won't be overwritten, as far as I can see)
until Packages is updated.  Yes, this leaves you with an old mirror
for a potentially long period of time, but at least it's consistent.

An option would be to add a "stable-in-process" distribution for
the adventurous.  This would only appear at mirrors with relatively
low bandwidth and long transition periods.

Of course, both of these options require a lot more space of the
mirror :-(

Also, dselect should probably (optionally) recheck the dependencies
after getting the packages to make sure that the packages received
actually do satisfy the dependency tree.

dselect doesn't seem very smart about large numbers of packages; maybe 
new users should be advised to do the installations incrementally.  It 
also would be helpful to add an outline feature (hiding/showing
contents below a header) to dselect.  (Yeah, I know, I ought to put
this in a separate report, but I don't feel like wrestling with the
transmission lags to check the bug list.)

Thanks for your attention to these problems.

Stephen Turnbull

-- 
                            Stephen J. Turnbull
Institute of Policy and Planning Sciences                    Yaseppochi-Gumi
University of Tsukuba                      http://turnbull.sk.tsukuba.ac.jp/
Tel: +81 (298) 53-5091;  Fax: 55-3849              turnbull@sk.tsukuba.ac.jp