Mail Archives: cygwin/2010/01/10/21:49:19
On 01/10/2010 07:20 PM, Steven Monai wrote:
> On 2010/01/10 3:00 PM, Christopher Faylor wrote:
<snip>
>> 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.
In the cases where it makes sense to do what you say, it also makes sense
to assume that the persons doing this know what they are doing. If that's the
case, then this is by definition not a problem (or at least not a problem for
the installer facility). If that's not the case, this is why we say "Don't
do this."
Someone who doesn't know what they are doing but still wants to do it is not
restricted from doing so. It is just those persons are not going to get
allot of
sympathy or debugging help from the list when something goes wrong. We
recommend what we recommend because that is what works the best for the
greatest numbers. Anyone that disregards the advice is on their own. And
given the rarity for the scenario you state, it hardly seems worth any priority
effort. In other words, I think you're going to have to step up and do this if
it's something you really want.
>> 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.
So your argument is based on the desire to have *another* package
manager application, besides 'setup.exe', that could be used from within
Cygwin applications to update Cygwin applications? Doesn't that seem like
allot of duplication of effort, considering that 'setup.exe' can already do
all of this, with the only caveat being that it should be run outside of
Cygwin apps and Cygwin apps should be shut down when doing so?
If this really seems like a good idea to you, you should look at the
email archives where all of this has been discussed before. You need
not agree with all the conclusions drawn, etc., but it makes sense to
familiarize yourself with what's been discussed already before opening
up these kinds of old threads.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746
_____________________________________________________________________
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?
--
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 -