This is the mail archive of the
mailing list for the Cygwin project.
Re: Is setup.exe _supposed_ to delete the cygwin dll before attempting to run shell scripts?
- From: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>
- To: Karl M <karlm30 at hotmail dot com>
- Cc: cygwin at cygwin dot com
- Date: Fri, 24 Sep 2004 17:22:22 -0400 (EDT)
- Subject: Re: Is setup.exe _supposed_ to delete the cygwin dll before attempting to run shell scripts?
- References: <BAY19-F13tlMazUSxvj00002643@hotmail.com>
- Reply-to: cygwin at cygwin dot com
On Fri, 24 Sep 2004, Karl M wrote:
> > From: Igor Pechtchanski Reply-To: cygwin@XXXXXX.XXX
> > To: Max Bowsher
> > CC: cygwin@XXXXXX.XXX
<http://cygwin.com/acronyms/#PCYMTNQREAIYR>, now with more reasons.
> > Subject: Re: Is setup.exe _supposed_ to delete the cygwin dll before
> > attempting to run shell scripts?
> > Date: Fri, 24 Sep 2004 15:30:44 -0400 (EDT)
> > On Fri, 24 Sep 2004, Max Bowsher wrote:
> > > Igor Pechtchanski wrote:
> > > > This is more likely to be the culprit -- postinstall scripts are
> > > > run after all the package files were installed. Unfortunately,
> > > > preremove script dependencies aren't easily computed from regular
> > > > package dependencies -- this has been discussed on cygwin-apps
> > > > some time ago.
> > >
> > > Couldn't this be trivially solved by running all preremove scripts
> > > in a batch, before actually beginning to delete files?
> > >
> > > Any flaw to that reasoning?
> > It'll work for simple programs, but not for packages where preremove
> > scripts erase files that are needed to run some programs from that
> > package. One example (not necessarily a perfect one) that comes to mind
> > right away is the base-files package, where the preremove script will
> > currently erase /etc/profile (so any script executing "bash -l" will not
> > get the expected results). I'm sure there are better examples...
> > FWIW, this is probably somewhat similar to the issue of circular
> > dependencies of postinstall scripts -- there is no good general solution
> > if we assume monolithic scripts.
> > Igor
> > > I guess I should now go and see how hard that would be to make happen...
> > > Max.
> Would it be easier to delay the deletion of the files. What I mean is in
> the preremove scripts, append the files to a list of "files to be
> deleted" instead of deleting them and not actually delete anything until
> all of the preremove scripts have run. Then delete the files in the
> list. Then remove the installed files.
That's one solution, but it implies a level of communication between the
preremove scripts and setup.exe that is currently non-existent. I suppose
as a quick-and-dirty solution one could set up a TO-REMOVE-MANIFEST file
somewhere (in /etc/preremove?) and require that all preremove scripts
appended files to be deleted into that file instead of actually deleting
them, but that isn't robust for a few reasons. One could even go a step
further and have setup.exe replace /bin/rm with a program that does the
required appending and leaves the files in place, but that's even less
robust (e.g., what if the preremove script checks afterwards that the file
really is deleted? or tries to create a *new* file in place of the old
one, which could have been read-only?).
Besides, this doesn't even begin to cover some more complex cases, like
preremove scripts renaming files instead of deleting them; mucking with
file contents (a la "sed -i"); and all other kinds of weird stuff one
doesn't expect to see in preremove scripts until someone decides to do
something "clever" and everything breaks.
I'm not downplaying your suggestion, and it might be a good short-term
workaround, but in the long term, some robust solution will have to be
|\ _,,,---,,_ firstname.lastname@example.org
ZZZzz /,`.-'`' -. ;-;;,_ email@example.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing." -- Dr. Jubal Harshaw
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html