Date: Mon, 25 Feb 2002 00:03:22 +0000 From: Thomas Hurst <tom.hurst@clara.net> To: ports@freebsd.org Subject: Re: cvs commit: ports/editors/vim Makefile distinfo Message-ID: <20020225000322.GA96590@voi.aagh.net> In-Reply-To: <20020224173004.E47910@over-yonder.net> References: <200202242127.g1OLRto12882@freefall.freebsd.org> <86r8na8rs9.wl@archon.musha.org> <20020224173004.E47910@over-yonder.net>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matthew D. Fuller (fullermd@over-yonder.net) wrote: > [ Shunted over to -ports ] > > On Mon, Feb 25, 2002 at 06:59:50AM +0900 I heard the voice of > Akinori MUSHA, and lo! it spake thus: > > At Sun, 24 Feb 2002 13:27:55 -0800 (PST), > > o`brien wrote: > > > obrien 2002/02/24 13:27:55 PST > > > > > > Modified files: > > > editors/vim Makefile distinfo > > > Log: > > > Update to Vim 6.0 patchlevel 270 > > > > That's a hell of a lot of patches... What I realized after adding the > > fifth patch to my portupgrade port was that I could never beat the vim > > port! :) Vim 6.1a was just announced, so it'll probably calm down a bit. Either that, or the port will switch to it and you'll have hundreds more patches to look forward to before release ;) > Is there a better way we can handle this general case of "A whole > bunch of patches"? > > Running 270 invocations of fetch(1), EACH of which sets up a > connection, pulls down <5k of data, and tears down, is painful as hell > (for the CLIENT, and I can't see how it's terribly healthy for the > server either). On my dialup, it takes 4-10 seconds for each patch, > of which MAYBE 2 seconds is data transfer. Yup, even on my cm it takes ages, cos it's mainly the latency between logging onto the ftp server, listing, cding, retring and quitting. > Ideally, of course, I'd learn toward ".tar.gz all the damn things > together and cut the total size by 3/4" or something, but I can see > how that could become a management nightmare. Doesn't work well progressively, since the tarball will change each time. If you're just updating you'll be grabbing all 150k of patches every time instead of the 2-3k patch. Plus there's the problems in gettting it mirrored etc. > Is there anything we can do to the overall build infrastructure to > allow fetching a set of files in a SINGLE connection, instead of doing > them all individually? Can fetch(1) be taught to handle globs or > wildcards, as a possibility? Try generating a pattern that'll match just the patches we want :) What we really need fetch to support is grabbing sets of files from alternative locations, and for it to be able to sort in an intelligent order for the minimum number of connections. Not impossible, but that's putting a lot of requirements on what's supposed to be a simple failsafe base system tool. Given the small number of ports like vim with so many files, it's a big requirement for a small problem. There's also the matter of resuming files, and skipping servers that are obviously unreliable/down/don't contain the files you want (just try fetching vim with a site override in effect) etc. I doubt anyone would disagree they would be nice, actually implimenting them is a pain.. A fetch target that generates a URL list and passes them to a command would be a start; I suppose someone could always find/write a tool for it and put it in ports.. -- Thomas 'Freaky' Hurst - freaky@aagh.net - http://www.aagh.net/ - Some men are alive simply because it is against the law to kill them. -- Ed Howe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020225000322.GA96590>