This is the mail archive of the cygwin 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: Update problems


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


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