setup

[Corinna Vinschen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20150625/cce0cdec/attachment.sig>