On Jul 3 15:31, Christopher Faylor wrote: > On Wed, Jul 03, 2013 at 09:06:53PM +0200, Corinna Vinschen wrote: > >On Jul 3 14:28, Christopher Faylor wrote: > >> What I'm leaning towards doing is creating a new "cache" directory which > >> just contains x86 and x86_64 directories with a setup.ini in each. I'd > >> get rid of the (IMO) stupid mangled site names since I don't think they > >> are really important and just download files directly into x86*/release. > >> setup.exe would only look in the architecture directory that it cared > >> about for setup.ini, ignoring the other architecture. > > > >Why introducing a new "cache" dir? If you drop the mangled site dir, > >you can just store the flattend directory structure below the local > >install dir without introducing another directory level (except of the > >x86/x86_64 subdirs, of course) > > It was just to distinguish that directory from other directories in the > download area. I thought that there might be a need to keep those > around for some reason although I guess that x86 and x86_64 would be ok > names to distinguish them from > > http%3a%2f%2fmirrors.kernel.org%2fsourceware%2fcygwin%2f > > though. > > I also wanted to give the directory a name that made it clear what it > does. I was even thinking of suggesting "deleteme". But, I don't > really feel strongly about this. > > >> If it's important than we could have setup do the old stupid way of > >> looking up and down in non-"cache" directories for setup.ini but I think > >> I'd like to retire that behavior. > > > >There would be no way anymore to support multiple different installation > >repositories, as with using cygwin and cygwinports in parallel. > > AFAIK, the only tenuous thing that keeps cygwin and cygwinports separate > is the list of the mirror name. The cygwinports web page even cautions > that you can't use the same mirror. > > The "cache" name could be user-configurable but I think I'd prefer > adding a "release" tag to setup.ini which controlled this, assuming that > Yaakov was ok with that. That would mean that it would be easier to use > normal sourceware mirrors with cygwinports. The cygwinports stuff would > show up in a separate directory automatically.
Hang on. If you always only look for setup.ini files in the $target or cache/$target subdir, without scanning the directories as today, how would setup be able to handle multiple setup.ini files at once, one from the Cygwin distro and one from cygwinports? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
