Op di 30-12-2003, om 13:18 schreef Colin Watson: > 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>'. Obviously. What I wanted to say is that the fact that madison is considerably more up-to-date than any mirror is probably its major advantage over using local stuff. Additionally, I don't usually need to check the status of many packages in bulk; however, to do the things I need to do in the most efficient way, access to the most up-to-date information is essential. > Of course, it should be obvious that madison's interface is useful to > me, otherwise I wouldn't have written a tool presenting it. :) Heh. [...] > > 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 > > point. > > In that case you'd already lost years ago. madison never displayed what > was in the incoming queue, I'm not claiming it does. However, it is my understanding that madison does output data about stuff which is already in auric's archive, but not sent to the mirrors yet. Did I misunderstand that? I'm not too familiar with katie's internals... > 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. That isn't true for me. I want to be able to check instantly whether some package is really compiled for my architecture or not (as said, usually wanna-build contains this information, but wanna-build can, at times, be in error). If it isn't, I want to put it in the needs-build queue again so that no time is lost on idling if the needs-build queue is rather empty; if it is, I definately do not want to do that, since that would result in a waste of time when a buildd picks up a package which was already built. Having the ability to cross-check that at the source (as in "the source server", not "the source code") is, as said, certainly preferable over going by Packages and Sources files from mirrors which may be up to a day out-of-sync. > 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. They do. As said, a web-interface would work for me -- I'm even willing to write that interface, if required (which shouldn't be too hard, even a single no-nonsense cgi script on auric could work) > 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. If my previous mail gave the impression that I consider your efforts worthless, then I wasn't clear enough; this will probably plug some hole left after closing up auric, but providing this (and nothing else) won't be enough, IMNSHO. Of course, if you're not working on auric, then all of this is moot anyway. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Most people have two reasons for doing anything -- a good reason, and the real reason
Attachment:
signature.asc
Description: Dit berichtdeel is digitaal ondertekend