Mail Archives: cygwin/2010/01/10/16:28:47
On 2010/01/10 12:31 PM, Eric Blake wrote:
> According to Christopher Faylor on 1/10/2010 12:27 PM:
>> No one thinks its a good idea.
>
> And here's one reason why. Newer versions of cygwin1.dll introduce new
> entry points. But suppose you are updating cygwin1.dll and bash at the
> same time. If the new bash depends on one of those new entry points, but
> the old cygwin1.dll is still in operation, then the replace-on-reboot
> won't save the fact that the new bash won't work until the reboot.
Okay, that is definitely a problem with my scenario. We don't want to
force an otherwise needless reboot every time cygwin1.dll is updated.
But what you describe is also a problem for setup.exe right now. To
reuse your example, if I run setup.exe to upgrade bash but I don't
upgrade cygwin1.dll at the same time (for whatever reason), then the new
bash won't work. More generally, if I upgrade package 'foo' but not
package 'bar'---and 'foo' uses new features of the new 'bar'---then
'foo' will not work.
Other package management systems deal with this problem by including
versioning in the package dependency specification. Thus one could, for
example, specify that 'foo' version 1.1 depends on 'bar' version >= 2.4.
So if I upgrade 'foo' to version 1.1, an upgrade to 'bar' is forced if
the currently installed 'bar' has version < 2.4.
> Really, it is better to stop ALL things cygwin, do the upgrade, and not
> worry about those interactions.
I would say it is certainly EASIER to do it that way, not necessarily
that it is better. Thank you for your time.
-SM
--
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -