This is the mail archive of the
mailing list for the Cygwin project.
Re: x86/ -> ./ symlink
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 1 Jul 2013 13:15:32 +0200
- Subject: Re: x86/ -> ./ symlink
- References: <878v1zo0q6 dot fsf at Rainer dot invalid> <20130629080152 dot GU2378 at calimero dot vinschen dot de> <20130629164600 dot GA1479 at ednor dot casa dot cgf dot cx> <20130629175908 dot GA5778 at ednor dot casa dot cgf dot cx> <20130630093846 dot GA2000 at calimero dot vinschen dot de> <20130630223132 dot GA5077 at ednor dot casa dot cgf dot cx> <20130701092301 dot GD2000 at calimero dot vinschen dot de>
- Reply-to: cygwin-apps at cygwin dot com
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