Re: recovery status update
[Please don't cc me on replies to mailing list posts; thanks.]
On Tue, Dec 30, 2003 at 11:05:07AM +0100, Wouter Verhelst wrote:
> Op di 30-12-2003, om 01:59 schreef Colin Watson:
> > On Mon, Dec 29, 2003 at 03:57:50PM -0500, Branden Robinson wrote:
> > > On Tue, Dec 09, 2003 at 07:06:13PM -0500, Clint Adams wrote:
> > > > - how to run madison and wanna-build
> > [...]
> > > Is there any progress on any of the above?
> > I've almost finished writing a tool with the same interface as madison
> > that works on Packages and Sources files, so can be run on any mirror.
> > (Naturally it's slower than the real thing.) I'll put it up for
> > experimentation shortly.
> That's not good enough. What makes madison interesting is _not_ its
> interface; rather, the fact that the information is up-to-date with the
> latest uploads.
Actually, I disagree; for me, when trying to figure out the versions of
large numbers of packages in a hurry (for working on the testing
scripts, usually), madison's interface knocks seven bells out of
anything else. I know how grep-dctrl works, but it's considerably more
tedious to use in bulk or for things like 'madison -S <source package>'.
Of course, it should be obvious that madison's interface is useful to
me, otherwise I wouldn't have written a tool presenting it. :)
> Madison has been a great help to me many times when people started
> asking questions on m68k-build about whether or not their packages were
> uploaded. It's happened that wanna-build contained slightly incorrect
> information (due to network outages between a buildd and the wanna-build
> database, human errors, and other such things that cannot easily be
> worked around by programming). In such situations, the ability to check
> whether a certain package is in the archive _now_ can be invaluable to
> do my work in a reasonable way. Losing that ability in the name of
> "security" is not acceptable.
> I can live with a "madison" -or similar- tool on another host being
> _slightly_ out-of-sync (say, at max 15 minutes or so), or with a
> web-interface that would replace madison for non-admins; but having to
> wait a full day (or rather, a full mirror pulse) for this kind of
> information being available is just too much. I know how to grep through
> a Packages- and a Sources-file, and compare them (there're packages
> called 'grep-dctrl' and 'quinn-diff' for a reason), but that's not the
In that case you'd already lost years ago. madison never displayed what
was in the incoming queue, which since New Incoming is effectively part
of the archive - in the sense that it can't arbitrarily be removed or
replaced except by uploading a new package with an increased version
number - and definitely indicates "uploaded". For me, the difference
between "uploaded plus whenever cron.daily runs" and "uploaded plus
whenever the mirror pulse to gluck happens" is pretty minor, since the
former might well be nearly a full day.
Anyhow, I'm not claiming that madison-lite will be able to replace all
uses of madison by everybody; for one thing, it really wants a certain
amount of disk space in your home directory to maintain a cache
(currently 12Mb for a full archive), so real remote database access
would certainly be better. If those couple of hours make a big
difference to you then fine, do continue to press for remote database
access. I do think, though, that the majority of the times I personally
have run madison the cron.daily versus mirror pulse distinction has been
largely irrelevant to me and I'd have been happy to run it on some other
machine if only the right interface had been there, so by extension I'm
guessing that such a facility will be useful to others too.
Colin Watson [email@example.com]