[lfs-dev] Latest packages

dueffert at uwe-dueffert.de dueffert at uwe-dueffert.de
Sat May 4 12:47:05 PDT 2013


On Sat, 4 May 2013, Bruce Dubbs wrote:

> dueffert at 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-
>> linux-
>> linux-
> 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)".


More information about the lfs-dev mailing list