delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2005/02/08/18:18:27

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Tue, 8 Feb 2005 18:18:01 -0500 (EST)
From: Igor Pechtchanski <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: "Swenson, Eric" <Eric DOT Swenson AT am DOT sony DOT com>
cc: cygwin AT cygwin DOT com
Subject: RE: bug in setup.exe?
In-Reply-To: <4FC99DFBEFD0D211888F0090272B96E3076012AC@us-sj-xmsg-4.am.sony.com>
Message-ID: <Pine.GSO.4.61.0502081808430.27816@slinky.cs.nyu.edu>
References: <4FC99DFBEFD0D211888F0090272B96E3076012AC AT us-sj-xmsg-4 DOT am DOT sony DOT com>
MIME-Version: 1.0

Eric,

Please make sure your mailer honors the Reply-To: field.  I set it for a
reason.  Thanks.

I've also reformatted your top-posted message.  Top-posting is rather
annoying -- if you can possibly avoid it, please do.

On Tue, 8 Feb 2005, Swenson, Eric wrote:

> > -----Original Message-----
> > From: Igor Pechtchanski [mailto:pechtcha AT XX DOT XXX DOT XXX]
> > Sent: Tuesday, February 08, 2005 2:59 PM
> > To: Swenson, Eric
> > Cc: cygwin AT XXXXXX DOT XXX

<http://cygwin.com/acronyms/#PCYMTNQREAIYR>.  Thanks.

> > Subject: Re: bug in setup.exe?
> >
> > On Tue, 8 Feb 2005, Swenson, Eric wrote:
> >
> > > I've run into the following situation on several machines now, at
> > > multiple times -- each with different versions of cygwin (so I'm not
> > > following the bug reporting procedure as I think the version
> > > information provided by cygcheck isn't really relevant and as I'm
> > > currently in a non-cygwin-working state as a result of this issue).
> > >
> > > Frequently, when running setup.exe and specifying that all packages
> > > should be installed (the mode I almost always use), setup.exe bombs
> > > while uninstalling a package that it knows it needs to update with
> > > the error that cygwin1.dll is not found.  Indeed, at the point the
> > > dialog box comes up telling me that cygwin1.dll wasn't found, if I
> > > check, it has indeed been deleted from my /bin directory (actually
> > > d:\cygwin\bin).  I suspect this is because setup has determined that
> > > it needs to upgrade my cygwin1.dll, and therefore must uninstall the
> > > old one first and then install the new one. The problem is, that
> > > either setup itself (doubtful) or one or more of the
> > > uninstall/install scripts needs cygwin1.dll in order to run
> > > successfully.
> > >
> > > Can anyone in the "know" tell me how this is supposed to work?
> >
> > This is indeed a (known, long-standing) bug in setup.exe.  The problem
> > is that some packages have pre-remove scripts that prepare a package
> > for removal.  These scripts are run when the packages are removed,
> > which happens in alphabetical order of package names, so the scripts
> > will bomb out if their packages happen to follow the "cygwin" package
> > alphabetically.
> >
> > It's clear that one needs to run all pre-remove scripts before
> > removing the actual package files.  It's also clear that the
> > alphabetical package name order is the wrong order to run pre-remove
> > scripts in.  What is not clear is what the right order is.
> > <http://cygwin.com/acronyms/#PTC>. :-)
> >
> > > I tried searching the mailing lists, but the cygwin site says that
> > > searching was disabled due to your recent disk crash.  I tried
> > > searching on google and only found one relevant reference
> > > (http://sources.redhat.com/ml/cygwin/2002-12/msg01346.html) and that
> > > page didn't lead me to any responses.
> > >
> > > If you press the ok button on the dialog telling you that
> > > cygwin1.dll was not found, setup proceeds with the next package.
> > > Frequently, I have to press OK many times (depending on the packages
> > > needing to be installed, of course) in order to get to the end of
> > > setup.  Sometimes I can get through with a successfull
> > > uninstall/install of the necessary packages and cygwin1.dll does get
> > > installed again.  But the packages whose uninstall/install depended
> > > on cygwin1.dll, of course, were not actually "correctly" uninstalled
> > > or installed.
> > >
> > > Ideas?  -- Eric
> >
> > One possible idea is to find out which packages have
> > pre-remove scripts
> > (run
> >
> > find /etc/preremove -type f | xargs cygcheck -f | sort -u
> >
> > to find those) and upgrade them before upgrading everything else.
> > This, of course, carries other problems with it (i.e., the postinstall
> > scripts may need the new versions of cygwin1.dll, etc).  Ultimately,
> > this needs to be fixed in setup.exe (once we figure out the right way
> > of doing it). There was some discussion of this in the cygwin-apps
> > archives (search for "preremove", I think).
> > 	Igor
>
> Thanks, Igor.  Would another possible solution be to have setup special
> case *only* the cygwin-dll package?  Have it run all the pre-remove
> scripts first, then if the cygwin-dll package needs updating, do that,
> and then do the rest?  Then, packages that have a dependency on
> cygwin1.dll in their scripts can be marked as needing to be run before
> (or after for post-remove) the cygwin-dll update.  Then, the actual
> ordering algorithm is simply: run pre-remove scripts, remove cygwin.dll,
> install new cygwin.dll, and then run post-remove scripts.
>
> -- Eric

In fact, there's no need to special-case cygwin1.dll -- just running the
pre-remove scripts in a batch before all the package files are removed
will work for 99% of the cases.  Feel free to submit a patch on that
one...

Doing it right in general is very tricky, though.  Suppose a pre-remove
script for package B needs to run "Atool" from package A.  But package A's
pre-remove script removes the files needed for Atool to work.  So, if the
pre-remove script for A is run first, by the time B's pre-remove script is
run, Atool no longer works, and thus B's pre-remove script fails.  The
discussions I pointed you to on cygwin-apps cover all this, BTW.

FWIW, I've yet to see a package that uses a post-remove script... :-)
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor AT watson DOT ibm DOT com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019