This is the mail archive of the 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: Upgrading Cygwin - postinstall difficulties?

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:
Problem reports:

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