Mail Archives: cygwin/2010/01/10/19:21:04
On 2010/01/10 3:00 PM, Christopher Faylor wrote:
> On Sun, Jan 10, 2010 at 01:28:34PM -0800, Steven Monai wrote:
>> 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.
>
> Yes, if you do something brain-dead you can expect bad results.
There can be non-"brain-dead" reasons for attempting to upgrade one
package while holding another related one at a specific version.
Granted, the situations where one might want to do this are probably few
and far between, but I suspect that the scenario Eric described is also
quite rare.
> That is
> different from doing a normal install, expecting things to work and
> being bitten by a non-updated cygwin DLL.
In my scenario, you would not be bitten by a non-updated cygwin DLL if
you rebooted after the update. The package manager could even give the
user a message like "A reboot is needed to complete the update. Things
may not work correctly until you do.". Most Windows users are probably
used to that sort of thing already.
>> 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.
>
> Now you've offered YA observation which has been made before. And it's
> one that would fix your hypothetical situation and not really touch the
> original concern unless you want to hold off all updates until the next
> reboot.
A reboot would be required only in the special case of an update to
'cygwin1.dll'. In all other cases, no reboot would be required, and
neither Eric's scenario, nor my generalization of it, would ever occur.
-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 -