Upgrading Cygwin - postinstall difficulties?

Upgrading Cygwin - postinstall difficulties?

[Andrew DeFaria]

Recently updating a Cygiwn 1.3.20 -> 1.5.3 I noticed something that 
concerns me. I think this problem is just a general problem and not sure 
what is "right" in this situation.

The postinstall scripts for 1.5.3 rely on executing commands that might 
have dependencies on the cygwin1.dll that has not been installed yet! If 
you are installing and cygwin1.dll is loaded then setup will not be able 
to put the new cygwin1.dll in place. Instead it puts it as 
cygwin1.dll.new and arranges for it to be put into place next reboot. 
However this does not stop the postinstall scripts from running. When a 
postinstall script runs it may execute say grep, but the new grep makes 
calls to a new or renamed function expecting to find it in the new 
cygwin1.dll. This fails and a dialog box is put up.

Now the situation is understandable. The question is: Did the 
postinstall script accomplish what it needed? After I reboot can I be 
assured that the "failed" postinstall script did enough of what it 
needed to do? Or should I re-execute (all) postinstall scripts?
===
Obligatory witty line: Mental Floss prevents Moral Decay.



--
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/

Re: Upgrading Cygwin - postinstall difficulties?

[Igor Pechtchanski]

On Tue, 16 Sep 2003, Andrew DeFaria wrote:

> Recently updating a Cygiwn 1.3.20 -> 1.5.3 I noticed something that
> concerns me. I think this problem is just a general problem and not sure
> what is "right" in this situation.
>
> The postinstall scripts for 1.5.3 rely on executing commands that might
> have dependencies on the cygwin1.dll that has not been installed yet! If
> you are installing and cygwin1.dll is loaded then setup will not be able
> to put the new cygwin1.dll in place. Instead it puts it as
> cygwin1.dll.new and arranges for it to be put into place next reboot.
> However this does not stop the postinstall scripts from running. When a
> postinstall script runs it may execute say grep, but the new grep makes
> calls to a new or renamed function expecting to find it in the new
> cygwin1.dll. This fails and a dialog box is put up.

Well, you shouldn't run setup with Cygwin processes running in the first
place.  I've been meaning to add an interactive dialog on failing to
replace cygwin1.dll that would let you kill Cygwin processes and retry the
replacement, but haven't got to it yet (and probably won't for quite a
bit).

> Now the situation is understandable. The question is: Did the
> postinstall script accomplish what it needed? After I reboot can I be
> assured that the "failed" postinstall script did enough of what it
> needed to do? Or should I re-execute (all) postinstall scripts?

The postinstall scripts obviously did not complete.  Also, since parts of
the postinstall scripts were executed, and other parts weren't, the system
is most likely in an unstable state.  Unfortunately, the corrective
actions depend heavily on the packages that were installed (e.g., if you
installed base-files for the first time, the postinstall scripts will have
created a possibly incorrect /etc/profile, but it won't be removed on
uninstall, so a reinstall of base-files won't give you a correct
/etc/profile; similarly with packages like apache).  You may have to look
at the individual postinstall scripts to see which actions need to be
reexecuted, and which need to be undone.  If a complete reinstall from
scratch is an option, I'd suggest that as the safest course.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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/

Re: Upgrading Cygwin - postinstall difficulties?

[Rich Elberger]

> Well, you shouldn't run setup with Cygwin processes running in the first
> place.  I've been meaning to add an interactive dialog on failing to
> replace cygwin1.dll that would let you kill Cygwin processes and retry the
> replacement, but haven't got to it yet (and probably won't for quite a
> bit).
>

this is difficult to do and keep installation integrity.  better might be
finding processes/file handles open in the cygwin install area after
choosing the installation target area, and not allowing install to continue
until those processes shut down.  this is a classic installation issue,
and if you don't have cancel and (graceful) rollback, there will be a
loophole for failure.

-- rich


--
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/

Re: Upgrading Cygwin - postinstall difficulties?

[Andrew DeFaria]

Igor Pechtchanski wrote:

> On Tue, 16 Sep 2003, Andrew DeFaria wrote:
>
> Well, you shouldn't run setup with Cygwin processes running in the 
> first place. 

Having the "install files in place" option where Cygwin tells you that 
some installed files were in use and you should reboot, sure gives about 
the impression that Cygwin will do the right thing.

> I've been meaning to add an interactive dialog on failing to replace 
> cygwin1.dll that would let you kill Cygwin processes and retry the 
> replacement, but haven't got to it yet (and probably won't for quite a 
> bit).

How about... If any files that were to be installed could not be because 
they are busy then, since you are arranging to have things done on 
reboot anyway, delay execution of all postinstall scripts until reboot. 
At reboot replace in use files then run postinstall scripts...

> The postinstall scripts obviously did not complete. Also, since parts 
> of the postinstall scripts were executed, and other parts weren't, the 
> system is most likely in an unstable state. 

Hmmm... system seems pretty stable... :-)

> Unfortunately, the corrective actions depend heavily on the packages 
> that were installed (e.g., if you installed base-files for the first 
> time, the postinstall scripts will have created a possibly incorrect 
> /etc/profile, but it won't be removed on uninstall, so a reinstall of 
> base-files won't give you a correct /etc/profile; similarly with 
> packages like apache). You may have to look at the individual 
> postinstall scripts to see which actions need to be reexecuted, and 
> which need to be undone. 

This is an unreasonable suggestion. Many people would have no idea how 
to determine which actions need to be re-executed and which to be 
undone. Most people are totally unaware of what postinstall scripts do - 
they just work - as they are supposed to.

A far better software engineering solution would be to make it such that 
postinstall scripts are re-executable in that they either postinstall or 
fix up as required.

> If a complete reinstall from scratch is an option, I'd suggest that as 
> the safest course.

Perhaps. Not sure I can get enough server time to accomplish this though...



--
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/

Re: Upgrading Cygwin - postinstall difficulties?

[Larry Hall]

At 11:37 AM 9/16/2003, Andrew DeFaria you wrote:
>Recently updating a Cygiwn 1.3.20 -> 1.5.3 I noticed something that concerns me. I think this problem is just a general problem and not sure what is "right" in this situation.
>
>The postinstall scripts for 1.5.3 rely on executing commands that might have dependencies on the cygwin1.dll that has not been installed yet! If you are installing and cygwin1.dll is loaded then setup will not be able to put the new cygwin1.dll in place. Instead it puts it as cygwin1.dll.new and arranges for it to be put into place next reboot. However this does not stop the postinstall scripts from running. When a postinstall script runs it may execute say grep, but the new grep makes calls to a new or renamed function expecting to find it in the new cygwin1.dll. This fails and a dialog box is put up.
>
>Now the situation is understandable. The question is: Did the postinstall script accomplish what it needed? After I reboot can I be assured that the "failed" postinstall script did enough of what it needed to do? Or should I re-execute (all) postinstall scripts?


At least for now, to be sure that things worked properly, you'd need to 
rerun the postinstall scripts after the new DLL has been put in place.
Either that or exit all Cygwin processes (including services) and rerun
setup reinstalling all the packages you just installed.

You're correct that this is not an issue specific to the 1.5.x upgrade 
process.


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


--
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/

Re: Upgrading Cygwin - postinstall difficulties?

[Igor Pechtchanski]

On Tue, 16 Sep 2003, Rich Elberger wrote:

> > Well, you shouldn't run setup with Cygwin processes running in the first
> > place.  I've been meaning to add an interactive dialog on failing to
> > replace cygwin1.dll that would let you kill Cygwin processes and retry the
> > replacement, but haven't got to it yet (and probably won't for quite a
> > bit).
> >
>
> this is difficult to do and keep installation integrity.  better might be
> finding processes/file handles open in the cygwin install area after
> choosing the installation target area, and not allowing install to continue
> until those processes shut down.  this is a classic installation issue,
> and if you don't have cancel and (graceful) rollback, there will be a
> loophole for failure.
>
> -- rich

I scratch my itch, you scratch yours. ;-)
<http://cygwin.com/acronyms/#PTC>.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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/

Re: Upgrading Cygwin - postinstall difficulties?

[Igor Pechtchanski]

On Tue, 16 Sep 2003, Larry Hall wrote:

> At 11:37 AM 9/16/2003, Andrew DeFaria you wrote:
> >Recently updating a Cygiwn 1.3.20 -> 1.5.3 I noticed something that
> >concerns me. I think this problem is just a general problem and not
> >sure what is "right" in this situation.
> >
> >The postinstall scripts for 1.5.3 rely on executing commands that might
> >have dependencies on the cygwin1.dll that has not been installed yet!
> >If you are installing and cygwin1.dll is loaded then setup will not be
> >able to put the new cygwin1.dll in place. Instead it puts it as
> >cygwin1.dll.new and arranges for it to be put into place next reboot.
> >However this does not stop the postinstall scripts from running. When a
> >postinstall script runs it may execute say grep, but the new grep makes
> >calls to a new or renamed function expecting to find it in the new
> >cygwin1.dll. This fails and a dialog box is put up.
> >
> >Now the situation is understandable. The question is: Did the
> >postinstall script accomplish what it needed? After I reboot can I be
> >assured that the "failed" postinstall script did enough of what it
> >needed to do? Or should I re-execute (all) postinstall scripts?
>
> At least for now, to be sure that things worked properly, you'd need to
> rerun the postinstall scripts after the new DLL has been put in place.
> Either that or exit all Cygwin processes (including services) and rerun
> setup reinstalling all the packages you just installed.
>
> You're correct that this is not an issue specific to the 1.5.x upgrade
> process.
>
> --
> Larry Hall

Larry,

I'd like to reiterate a warning that even a reinstall might not bring the
system into a stable state if postinstall scripts were only partially
executed.  I'm perfectly willing to give examples of situations where this
will be true, but don't want to pollute the list unless there's general
interest.

Andrew's suggestion about delaying postinstall scripts until reboot sounds
reasonable (or at least as reasonable as my suggestion of letting the user
kill processes and retrying the replacement).  The current setup *is*
broken in that regard.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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/

Re: Upgrading Cygwin - postinstall difficulties?

[Igor Pechtchanski]

On Tue, 16 Sep 2003, Andrew DeFaria wrote:

> Igor Pechtchanski wrote:
>
> > On Tue, 16 Sep 2003, Andrew DeFaria wrote:
> >
> > Well, you shouldn't run setup with Cygwin processes running in the
> > first place.
>
> Having the "install files in place" option where Cygwin tells you that
> some installed files were in use and you should reboot, sure gives about
> the impression that Cygwin will do the right thing.

Yes, it does.  As I already said, setup is broken in this regard.

> > I've been meaning to add an interactive dialog on failing to replace
> > cygwin1.dll that would let you kill Cygwin processes and retry the
> > replacement, but haven't got to it yet (and probably won't for quite a
> > bit).
>
> How about... If any files that were to be installed could not be because
> they are busy then, since you are arranging to have things done on
> reboot anyway, delay execution of all postinstall scripts until reboot.
> At reboot replace in use files then run postinstall scripts...

This is reasonable.  Feel free to contribute a patch. ;-)

> > The postinstall scripts obviously did not complete. Also, since parts
> > of the postinstall scripts were executed, and other parts weren't, the
> > system is most likely in an unstable state.
>
> Hmmm... system seems pretty stable... :-)

Lucky you.  Let's hope it is.

> > Unfortunately, the corrective actions depend heavily on the packages
> > that were installed (e.g., if you installed base-files for the first
> > time, the postinstall scripts will have created a possibly incorrect
> > /etc/profile, but it won't be removed on uninstall, so a reinstall of
> > base-files won't give you a correct /etc/profile; similarly with
> > packages like apache). You may have to look at the individual
> > postinstall scripts to see which actions need to be reexecuted, and
> > which need to be undone.
>
> This is an unreasonable suggestion. Many people would have no idea how
> to determine which actions need to be re-executed and which to be
> undone. Most people are totally unaware of what postinstall scripts do -
> they just work - as they are supposed to.

This is one solution that is guaranteed to work.  The fact that people
won't know how to do this indicates that setup *should* handle things
better.  It currently doesn't.

Luckily, most people who won't have the expertise to wade through
postinstall scripts will probably also lack the ability to customize their
Cygwin installation so heavily that a complete reinstall from scratch
isn't an option.

> A far better software engineering solution would be to make it such that
> postinstall scripts are re-executable in that they either postinstall or
> fix up as required.

This is not under setup's control.  Postinstall scripts are written by
individual package maintainers.  Most of them *are* reexecutable, or, at
least, don't do anything that can't be redone.  Some, however, modify
existing state of the system, either in-place or conditionally on the
non-existence of this previous state (i.e., new install).  In both of
these cases, there's a potential for failure, and the scripts will
probably not be reexecutable.  A list of such scripts might be a useful
thing to have in the archives.

> > If a complete reinstall from scratch is an option, I'd suggest that as
> > the safest course.
>
> Perhaps. Not sure I can get enough server time to accomplish this though...

This is another solution that's guaranteed to work (but may not be worth
the trouble if you've customized your installation).
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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/

Re: Upgrading Cygwin - postinstall difficulties?

[Andrew DeFaria]

Igor Pechtchanski wrote:

> This is not under setup's control. Postinstall scripts are written by 
> individual package maintainers. Most of them *are* reexecutable, or, 
> at least, don't do anything that can't be redone. Some, however, 
> modify existing state of the system, either in-place or conditionally 
> on the non-existence of this previous state (i.e., new install). In 
> both of
> these cases, there's a potential for failure, and the scripts will 
> probably not be reexecutable. A list of such scripts might be a useful 
> thing to have in the archives.

What I was saying is that the writers of postinstall scripts should be 
mindful that their scripts are re-runnable. And for the few instances 
where a postinstall script relies on things like the non-existence of a 
previous state that they should perhaps provide a option, say 
-reinstall, that would set the situation as if it was a new install.
===
Obligatory witty saying: Always remember you're unique... Just like 
everyone else.



--
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/

Setup installation order?

[Rick Rankin]

I ran into a situation I hadn't seen before a few days ago when I used setup to
update my Cygwin installation from 1.5.3 to 1.5.4. What happened was that there
were several packages, in addition to cygwin-1.5.4, that had updates available.
Setup downloaded the updates, then uninstalled the old packages, including
cygwin-1.5.3. When it went to install the updates, cygwin-1.5.4 was *not* the
first package that got installed, so any postinstallion scripts failed with a
dialog box from the O/S saying that "Windows cannot find cygwin1.dll in <path
list>" until after cygwin itself was updated. After setup installed the cygwin
package, the rest of the postinstall scripts ran fine.

Is the cygwin package given any special consideration during the install
process (e.g., last to be uninstalled, first to be (re)installed), or is this
something that's expected to be handled by the dependency list? I've been
perusing the setup sources, but I haven't quite figured out the dependency
processing, yet. So far, I haven't found anything related via Google searches,
either.

--Rick


--
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/

Re: Setup installation order?

[Rich Elberger]

On Tue, 16 Sep 2003, Rick Rankin wrote:

> I ran into a situation I hadn't seen before a few days ago when I used setup to
> update my Cygwin installation from 1.5.3 to 1.5.4. What happened was that there
> were several packages, in addition to cygwin-1.5.4, that had updates available.
> Setup downloaded the updates, then uninstalled the old packages, including
> cygwin-1.5.3. When it went to install the updates, cygwin-1.5.4 was *not* the
> first package that got installed, so any postinstallion scripts failed with a
> dialog box from the O/S saying that "Windows cannot find cygwin1.dll in <path
> list>" until after cygwin itself was updated. After setup installed the cygwin
> package, the rest of the postinstall scripts ran fine.
>
> Is the cygwin package given any special consideration during the install
> process (e.g., last to be uninstalled, first to be (re)installed), or is this
> something that's expected to be handled by the dependency list? I've been
> perusing the setup sources, but I haven't quite figured out the dependency
> processing, yet. So far, I haven't found anything related via Google searches,
> either.

There is no dependency work for the postinstalls.

http://cygwin.com/setup.html#postinstall

>
> --Rick
>
>
> --
> 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/
>
>

--
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/

Re: Setup installation order?

[Igor Pechtchanski]

On Tue, 16 Sep 2003, Rick Rankin wrote:

> I ran into a situation I hadn't seen before a few days ago when I used
> setup to update my Cygwin installation from 1.5.3 to 1.5.4. What
> happened was that there were several packages, in addition to
> cygwin-1.5.4, that had updates available. Setup downloaded the updates,
> then uninstalled the old packages, including cygwin-1.5.3. When it went
> to install the updates, cygwin-1.5.4 was *not* the first package that
> got installed, so any postinstallion scripts failed with a dialog box
> from the O/S saying that "Windows cannot find cygwin1.dll in <path
> list>" until after cygwin itself was updated. After setup installed the
> cygwin package, the rest of the postinstall scripts ran fine.
>
> Is the cygwin package given any special consideration during the install
> process (e.g., last to be uninstalled, first to be (re)installed), or is
> this something that's expected to be handled by the dependency list?
> I've been perusing the setup sources, but I haven't quite figured out
> the dependency processing, yet. So far, I haven't found anything related
> via Google searches, either.
>
> --Rick

The setup program simply performs a topological sort of the package
dependence graph, and then traverses the packages in that order.  Of
course, since the graph is cyclic, topological order is not unique.  In
any case, the postinstall scripts should run after *all* the packages are
unpacked, so you shouldn't be missing cygwin1.dll on postinstall.

However, preremove scripts are run just before the corresponding package
is removed (in alphabetical order, IIRC).  This presents a problem, but
noone so far has considered it a large enough problem to invest the effort
in a fix.  It's likely that you saw this particular problem in your
upgrade.  <http://cygwin.com/acronyms/#PTC>.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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/

Re: Setup installation order?

[Igor Pechtchanski]

On Tue, 16 Sep 2003, Rich Elberger wrote:

> On Tue, 16 Sep 2003, Rick Rankin wrote:
>
> > I ran into a situation I hadn't seen before a few days ago when I used
> > setup to update my Cygwin installation from 1.5.3 to 1.5.4. What
> > happened was that there were several packages, in addition to
> > cygwin-1.5.4, that had updates available. Setup downloaded the
> > updates, then uninstalled the old packages, including cygwin-1.5.3.
> > When it went to install the updates, cygwin-1.5.4 was *not* the first
> > package that got installed, so any postinstallion scripts failed with
> > a dialog box from the O/S saying that "Windows cannot find cygwin1.dll
> > in <path list>" until after cygwin itself was updated. After setup
> > installed the cygwin package, the rest of the postinstall scripts ran
> > fine.
> >
> > Is the cygwin package given any special consideration during the
> > install process (e.g., last to be uninstalled, first to be
> > (re)installed), or is this something that's expected to be handled by
> > the dependency list? I've been perusing the setup sources, but I
> > haven't quite figured out the dependency processing, yet. So far, I
> > haven't found anything related via Google searches, either.
>
> There is no dependency work for the postinstalls.
>
> http://cygwin.com/setup.html#postinstall

Umm, actually, the above is incorrect.  I clearly remember rephrasing that
section of the webpage, and the patch seems to have been lost.  I'll
resubmit it.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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/

Re: Setup installation order?

[Rick Rankin]

--- Igor Pechtchanski <pechtcha@cs.nyu.edu> wrote:
> On Tue, 16 Sep 2003, Rick Rankin wrote:
> 
> > I ran into a situation I hadn't seen before a few days ago when I used
> > setup to update my Cygwin installation from 1.5.3 to 1.5.4. What
> > happened was that there were several packages, in addition to
> > cygwin-1.5.4, that had updates available. Setup downloaded the updates,
> > then uninstalled the old packages, including cygwin-1.5.3. When it went
> > to install the updates, cygwin-1.5.4 was *not* the first package that
> > got installed, so any postinstallion scripts failed with a dialog box
> > from the O/S saying that "Windows cannot find cygwin1.dll in <path
> > list>" until after cygwin itself was updated. After setup installed the
> > cygwin package, the rest of the postinstall scripts ran fine.
> >
> > Is the cygwin package given any special consideration during the install
> > process (e.g., last to be uninstalled, first to be (re)installed), or is
> > this something that's expected to be handled by the dependency list?
> > I've been perusing the setup sources, but I haven't quite figured out
> > the dependency processing, yet. So far, I haven't found anything related
> > via Google searches, either.
> >
> > --Rick
> 
> The setup program simply performs a topological sort of the package
> dependence graph, and then traverses the packages in that order.  Of
> course, since the graph is cyclic, topological order is not unique.  In
> any case, the postinstall scripts should run after *all* the packages are
> unpacked, so you shouldn't be missing cygwin1.dll on postinstall.
> 
> However, preremove scripts are run just before the corresponding package
> is removed (in alphabetical order, IIRC).  This presents a problem, but
> noone so far has considered it a large enough problem to invest the effort
> in a fix.  It's likely that you saw this particular problem in your
> upgrade.  <http://cygwin.com/acronyms/#PTC>.

Ahh, that's entirely possible. At the time, I wasn't paying enough attention to
notice whether the problem occurred during preremove or postinstall. For
whatever reason, I *assumed* it occurred during postinstall.

If that's the case, this particular problem could be solved by pushing the
cygwin package to the end of the package removal list, which is probably where
it should be anyway; however, that wouldn't solve the more general ordering
problem. Time permitting... ;-)

--Rick

--
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/

Re: Upgrading Cygwin - postinstall difficulties?

[Larry Hall]

At 12:40 PM 9/16/2003, Igor Pechtchanski you wrote:
>On Tue, 16 Sep 2003, Larry Hall wrote:
>
>> At 11:37 AM 9/16/2003, Andrew DeFaria you wrote:


<snip>



>> >
>> >Now the situation is understandable. The question is: Did the
>> >postinstall script accomplish what it needed? After I reboot can I be
>> >assured that the "failed" postinstall script did enough of what it
>> >needed to do? Or should I re-execute (all) postinstall scripts?
>>
>> At least for now, to be sure that things worked properly, you'd need to
>> rerun the postinstall scripts after the new DLL has been put in place.
>> Either that or exit all Cygwin processes (including services) and rerun
>> setup reinstalling all the packages you just installed.
>>
>> You're correct that this is not an issue specific to the 1.5.x upgrade
>> process.
>>
>> --
>> Larry Hall
>
>Larry,
>
>I'd like to reiterate a warning that even a reinstall might not bring the
>system into a stable state if postinstall scripts were only partially
>executed.  I'm perfectly willing to give examples of situations where this
>will be true, but don't want to pollute the list unless there's general
>interest.
>
>Andrew's suggestion about delaying postinstall scripts until reboot sounds
>reasonable (or at least as reasonable as my suggestion of letting the user
>kill processes and retrying the replacement).  The current setup *is*
>broken in that regard.
>    Igor


I don't disagree with your statements Igor.  I actually sent my response
well before yours arrived in my mailbox.  I don't know why it took so long
for mine to filter through the list.  No matter.  Anyway, if I had seen your 
response before I sent mine, I wouldn't have bothered, since yours is a more
complete reply.


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


--
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/

Re: Setup installation order?

[Robert Collins]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

On Wed, 2003-09-17 at 03:49, Rick Rankin wrote:
> Is the cygwin package given any special consideration during the install
> process (e.g., last to be uninstalled, first to be (re)installed), or is this
> something that's expected to be handled by the dependency list? I've been
> perusing the setup sources, but I haven't quite figured out the dependency
> processing, yet. So far, I haven't found anything related via Google searches,
> either.

Setup performs removals, replacements, new installs, in that order.

Once all file copies are complete, postinstall scripts are run, in
topological order (using strongly connected graph traversal). So you
problem was most likely during the replacement phase. 

The setup.log.full and setup.log would be essential to diagnose the
problem.

Rob
-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Setup installation order?

[Rolf Campbell]

Igor Pechtchanski wrote:

> On Tue, 16 Sep 2003, Rick Rankin wrote:
>>I ran into a situation I hadn't seen before a few days ago when I used
>>setup to update my Cygwin installation from 1.5.3 to 1.5.4. What
>>happened was that there were several packages, in addition to
>>cygwin-1.5.4, that had updates available. Setup downloaded the updates,
>>then uninstalled the old packages, including cygwin-1.5.3. When it went
>>to install the updates, cygwin-1.5.4 was *not* the first package that
>>got installed, so any postinstallion scripts failed with a dialog box
>>from the O/S saying that "Windows cannot find cygwin1.dll in <path
>>list>" until after cygwin itself was updated. After setup installed the
>>cygwin package, the rest of the postinstall scripts ran fine.
>>
>>Is the cygwin package given any special consideration during the install
>>process (e.g., last to be uninstalled, first to be (re)installed), or is
>>this something that's expected to be handled by the dependency list?
>>I've been perusing the setup sources, but I haven't quite figured out
>>the dependency processing, yet. So far, I haven't found anything related
>>via Google searches, either.
>>
>>--Rick
> 
> 
> The setup program simply performs a topological sort of the package
> dependence graph, and then traverses the packages in that order.  Of
> course, since the graph is cyclic, topological order is not unique.  In
> any case, the postinstall scripts should run after *all* the packages are
> unpacked, so you shouldn't be missing cygwin1.dll on postinstall.
> 
> However, preremove scripts are run just before the corresponding package
> is removed (in alphabetical order, IIRC).  This presents a problem, but
> noone so far has considered it a large enough problem to invest the effort
> in a fix.  It's likely that you saw this particular problem in your
> upgrade.  <http://cygwin.com/acronyms/#PTC>.
> 	Igor

Wouldn't it make sence to call each preremove script before any packages 
are actually removed?



--
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/

Re: Setup installation order?

[Igor Pechtchanski]

On Tue, 16 Sep 2003, Rolf Campbell wrote:

> Igor Pechtchanski wrote:
>
> > On Tue, 16 Sep 2003, Rick Rankin wrote:
> >>I ran into a situation I hadn't seen before a few days ago when I used
> >>setup to update my Cygwin installation from 1.5.3 to 1.5.4. What
> >>happened was that there were several packages, in addition to
> >>cygwin-1.5.4, that had updates available. Setup downloaded the updates,
> >>then uninstalled the old packages, including cygwin-1.5.3. When it went
> >>to install the updates, cygwin-1.5.4 was *not* the first package that
> >>got installed, so any postinstallion scripts failed with a dialog box
> >>from the O/S saying that "Windows cannot find cygwin1.dll in <path
> >>list>" until after cygwin itself was updated. After setup installed the
> >>cygwin package, the rest of the postinstall scripts ran fine.
> >>
> >>Is the cygwin package given any special consideration during the install
> >>process (e.g., last to be uninstalled, first to be (re)installed), or is
> >>this something that's expected to be handled by the dependency list?
> >>I've been perusing the setup sources, but I haven't quite figured out
> >>the dependency processing, yet. So far, I haven't found anything related
> >>via Google searches, either.
> >>
> >>--Rick
> >
> >
> > The setup program simply performs a topological sort of the package
> > dependence graph, and then traverses the packages in that order.  Of
> > course, since the graph is cyclic, topological order is not unique.  In
> > any case, the postinstall scripts should run after *all* the packages are
> > unpacked, so you shouldn't be missing cygwin1.dll on postinstall.
> >
> > However, preremove scripts are run just before the corresponding package
> > is removed (in alphabetical order, IIRC).  This presents a problem, but
> > noone so far has considered it a large enough problem to invest the effort
> > in a fix.  It's likely that you saw this particular problem in your
> > upgrade.  <http://cygwin.com/acronyms/#PTC>.
> >       Igor
>
> Wouldn't it make sence to call each preremove script before any packages
> are actually removed?

It would make sense.  It's currently not done that way.  PTC.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
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/