On Mon, Jul 01, 2013 at 06:40:17PM +0200, Corinna Vinschen wrote: >On Jul 1 17:18, Corinna Vinschen wrote: >> On Jul 1 14:50, Corinna Vinschen wrote: >> > Here's a patch which should do the trick. I'm deliberately not applying >> > it so that I don't colide with anything you already have in the loop. >> >> Scratch it. The general idea might be ok, but it just doesn't work if >> the local dir is not a mirror, but rather the installation directory as >> fetched via setup itself. In this case, the setup.ini files are not in >> top-level, but rather one level below top-level. This has to be taken >> into account. >> >> On the other hand, if the local dir is a mirror, there are now four >> setup.ini files, the 32 bit setup.ini in top-level and the x86 dir, >> and the 64 bit setup.ini in x86_64 and the 64bit subdirs, and setup >> will read all four of them. >> >> The long loading time was always a bit annoying, but other than that it >> was no problem, as long as there were only two ini files and the 64 bit >> file was called setup64.ini. Oh well. > >(Hopefully last) followup to my monologue: > >I think I have a solution now. I detached the "x86" and "x86_64" target >subdirs from SETUP_INI_FILENAME and introduced a SETUP_INI_DIR instead. >Changing the Find class to allow a maximum tracking depth, plus an >additional check to make sure the found file is the one from the target >subdir, this should work now in all circumstances. > >See below. Again, not applied to not collide with what you have.
I don't have anything like this in the pipeline but this is pretty much what I concluded that I needed to do while laying in bed last night and in the special thinking room. I didn't look at the patch. Does it just put setup.ini right under the mangled download url directory*? That's what I was going to do. But, anyway, if you have something that works please check it in. cgf *I dislike the mangled download directory almost as much as I dislike the maze of twisty little packages in the setup source code.
