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]

Re: x86/ -> ./ symlink

On Jul  1 11:23, Corinna Vinschen wrote:
> On Jun 30 18:31, Christopher Faylor wrote:
> > On Sun, Jun 30, 2013 at 11:38:46AM +0200, Corinna Vinschen wrote:
> > >On Jun 29 13:59, Christopher Faylor wrote:
> > >> On Sat, Jun 29, 2013 at 12:46:00PM -0400, Christopher Faylor wrote:
> > >> >On Sat, Jun 29, 2013 at 10:01:52AM +0200, Corinna Vinschen wrote:
> > >> >>On Jun 24 19:52, Achim Gratz wrote:
> > >> >>> 
> > >> >>> May I suggest that this sort of link (and the similar one in
> > >> >>> cygwinports) has potential to break mirror scripts in bad ways?  Not
> > >> >>> quite as bad, but linking x86_64 -> 64bit also results in duplicates
> > >> >>> that aren't serving a good purpose.
> > >> >>
> > >> >>The x86 symlink break the "Install from directory" function of
> > >> >>setup.exe.  It runs into some endless loop.  If I remove the symlinks it
> > >> >>works as usual.  I don't know why it does that at all.  It has no
> > >> >>business reading these symlinks.  If nobody beats me to it, I'll
> > >> >>investigate next week.
> > >> >
> > >> >Are you saying that this is happening with a CVS version of setup.exe?
> > >
> > >No, this occurs with the current 2.774 version from the home page.
> > >
> > >> >If not, it seems impossible that this symlink would cause an issue on a
> > >> >local install.
> > >> >
> > >> >Or, maybe you're copying the whole release area to your work area as
> > >> >you proposed in the cygwin list.
> > >
> > >We're using a local mirror and "Install from directory" from the local
> > >mirror for many, many years and it always worked fine.
> > 
> > I'm still investigating this behavior.
> I'll have a look, too.  The 64 bit version now also misbehaves like the
> 32 bit version in terms of showing a broken package list.  A first
> debugging attempt shows that it now neglects to parse the .ini file at
> all for some reason.

I found the reason for not finding the local setup.ini file anymore.
The much too complex algorithm scans the *entire* tree below the local
package dir for a file called SETUP_INI_FILENAME.  The problem now is
that it compares SETUP_INI_FILENAME against the filename returned by
FindFileNext.  Since SETUP_INI_FILENAME now includes a path component
(x86/x86_64), the search doesn't work anymore.  And after that, when it
didn't find the file, it scans the entire tree another time to collect
file information for all files in the tree to be able to go ahead
without setup.ini file.

I'm just struggling with the idiotically complex C++ class system.
I thought I just simplify the do_fromcwd function to just check for the
file, but now I have another weird effect.  After setup spends some time
in the progress dialog, it suddenly is back to dialog #2, "Choose A
Download Source".  Incredible how that's possible at all.  How I wish
setup would have been written in plain C.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]