Hi, On Sat, 4 May 2013, Bruce Dubbs wrote:
> dueff...@uwe-dueffert.de wrote: >> >> Current solution (that I'm happy with for quite some years): >> All parsing stuff is done by a simple single C(++?) program now. >> It basically follows _all_ links and handles general stuff like stripping >> common extensions (*.tgz etc) or an appended "/download" and replacing >> "/from/a/mirror" by "/from/this/mirror". > I'm using php. It is generally easier to maintain than C/C++. Well, whatever you prefer. > php can do anything C can and the computation time is not an issue for > this type of application. The most time used will be fetching directory > listings from remote sites. Yeah. My point here was just that it is useful to write something in C/php/whatever instead of only using scripts, because something like a grep on a 200KB file for every potential link just to check whether you already have that package/directory IS time comsuming as well... >> autoconf-2.52 >> autoconf-2.53 >> autoconf-2.54 >> linux-2.6.16.18-utf8_input-1.patch >> linux-2.6.16.19 >> linux-2.6.16.19-utf8_input-1.patch > Actually, I want to know if a xz version exists. My order of preference > is xz, bz2, gz. Same here. But my consequences are different (and probably not suitable for LFS): I convert everything to xz that is only available as bz2 or gz (neither computation time nor bandwitdth is an issue on the machine fetching it). This saves me considerable amounts of time and space when transfering it to machines where this is an issue. Therefore I do not care (or remember) in which format a certain package appeared first. I do have it and its locally stored as xz anyway. That said, there is room for improvement: Currently I might miss the maintainer decision to change the most prefered format he offers. I'll probably add something to check in order of above preference. Thanks for the insight :-) > This does give me a couple of ideas to play with. Thanks. Glad to hear that. Usually its the other way around (LFS giving me ideas). I could provide the ugly code (which you are going to rewrite anyway) or my current (potentially incomplete or outdated) rule/exclusion lists, but I figured explaining the general idea is more useful here. Well, and I cannot emphasize enough how dramatically the maintenance effort was reduced by switching from numerous and always subject to change naming/versioning/structuring match rules to "just follow all links and have an exclusion list (or actually two)". Uwe -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
