This is the mail archive of the cygwin-apps mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Jun 24 22:00, Achim Gratz wrote: > Corinna Vinschen writes: > >> What's the expected directory structure here? > > > > In the usual case ("Install from Internet") the local package directory > > contains a separate subdir for each mirror chosen from the mirror dialog: > > > > Local package directory > > | > > +-> Mirror1 subdir > > | | > > | +-> x86 > > | | | > > | | +-> setup.ini > > | | > > | +-> x86_64 > > | | > > | +-> setup.ini > > | > > +-> Mirror2 subdir > > | | > > | +-> x86 > > | | | > > | | +-> setup.ini > > | | > > | +-> x86_64 > > | | > > | +-> setup.ini > > . > > . > > . > > I've looked at what the original code was doing (or what I think it was > doing). Besides the case that you show, it would also find a setup.ini > if the local directory was set one or two levels down (into the mirror > level or the architectire subtree level, respectively). The problem is that the existing algorithm is rather dump. The recursive search class is, IMHO, C++ at its worst. In fact, the original code (you should be able to look this up in the git history if I didn't screw this up during the cvs->git move) didn't stop at the 2nd level but searched the whole tree below the local package dir. I added the "search only two levels" at one point as a band-aid since I wasn't sure if ripping out the class wouldn't break anything. Having said that, any more intelligent algorithm searching only where it actually makes sense, would be real progress. More C than C++ wouldn't hurt either. > In the latter > case, the local directory was required to have its last component the > correct architecture. I think I have cooked up a solution to do this > (not yet fully implemented nor tested), but the code would be cleaner if > the local package directory would never be at the same level where > setup.ini resides (which necessitates to extract the last path component > and check for the correct architecture). I'm not sure I understand what you're saying. Setup.ini should never be at the local package directory level is my understanding. Local package directory is either a local mirror, in which case you'd have to expect this structure: Local MIRROR directory | +-> x86 | | | +-> setup.ini | +-> x86_64 | | | +-> setup.ini | +-> noarch (just would be nice at one point) or it's the normal user case of a local package directory containing (partial) mirrors of Cygwin mirrors as outlined in my original ASCII art. AFAICS we can expect these two and don't have to care for anything else. > So the question is if that was maybe an accidental feature that can be > removed? The code would become a bit cleaner. If anybody was using it > inadvertently, they just need to remove that last component form the > local package directory, so there's no loss of functionality that I can > see. > > There's another accidental feature (I think) in that old code in that > you could mix two package sources at different levels like this: > > > Local package directory (ending in /x86) ^^^^^^^^^^^^^^^^ This is a no-no > > | > > +-> Mirror1 subdir > > | | > > | +-> x86 > > | | | > > | | +-> setup.ini ^^^^^^^^^^^^^ Downloading from mirrors > > | | > > | +-> x86_64 > > | | > > | +-> setup.ini > > +-> x86 > > | | > > | +-> setup.ini ^^^^^^^^^^^^^ Local package directory is a mirror itself > > | > > +-> setup.ini ^^^^^^^^^ Ignore this > and setup-x86.exe would find three setup.ini. I think that's a mistake It was not a mistake a couple of years ago. Keep in mind that we originally only had one platform and no x86 and x86_64 subdirs. Therefore, finding the top-level setup.ini (the bottom one in your ASCII art) was required when we moved to a multi-arch approach. However. - It would only have been correct for x86, never for x86_64. - It's absolutely outdated these days. > and I would want to truncate the search at the first level a setup.ini > has been found (in this example only the one in the local package > directory). Strictly, we don't have to support updates from the old non-multi-arch setup anymore, therefore any top-level setup.ini can be ignored. So, from my POV, the search should ideally work like this: - Start at Local package directory. - Look if a $arch subdir exists. If so, does it have setup.ini? If so collect it and stop here. - Otherwise search all immediate subdirs. Look if they have a $arch subdir. If so, does it have setup.ini? If so, collect it. Does that make sense? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
pgpWUcT9olwaV.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |