X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 	tests=AWL,BAYES_00,SPF_HELO_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <4B4A90C8.2040406@cygwin.com>
Date: Sun, 10 Jan 2010 21:45:28 -0500
From: "Larry Hall (Cygwin)" <reply-to-list-only-lh AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090320 Remi/2.0.0.21-1.fc8.remi Lightning/0.9 Thunderbird/2.0.0.21 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Update problems
References: <web-28750510 AT remus DOT csulb DOT edu>  <4B46A4C3 DOT 2000803 AT cygwin DOT com>  <4B47986F DOT 2020609 AT t-online DOT de>  <4B47B3FA DOT 1010101 AT cygwin DOT com>  <4B47DBAE DOT 5000901 AT monai DOT ca>  <20100109100941 DOT GL23992 AT calimero DOT vinschen DOT de>  <4B4A1032 DOT 9030201 AT monai DOT ca>  <20100110192728 DOT GC24855 AT ednor DOT casa DOT cgf DOT cx>  <4B4A3918 DOT 4020005 AT byu DOT net>  <4B4A4682 DOT 9040002 AT monai DOT ca> <20100110230049 DOT GA25743 AT ednor DOT casa DOT cgf DOT cx> <4B4A6EE2 DOT 9040406 AT monai DOT ca>
In-Reply-To: <4B4A6EE2.9040406@monai.ca>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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