delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2010/04/10/23:22:12

X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=1.7 required=5.0 tests=BAYES_50,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,SPF_HELO_PASS,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Paul Bibbings <paul DOT bibbings AT gmail DOT com>
Subject: Re: How to uninstall Cygwin/X (only)
Date: Sun, 11 Apr 2010 04:21:41 +0100
Lines: 40
Message-ID: <87r5mmad2y.fsf@gmail.com>
References: <r2keb3a2d501004081157x916548ebu8e4c17c46953e322 AT mail DOT gmail DOT com> <4BBE2F37 DOT 1060303 AT cygwin DOT com> <83y6gx330e DOT fsf AT torus DOT sehlabs DOT com> <83tyrl32lq DOT fsf AT torus DOT sehlabs DOT com> <4BBE886F DOT 409 AT cwilson DOT fastmail DOT fm> <4BBE99F4 DOT 2080405 AT gmail DOT com> <877hoheypo DOT fsf AT gmail DOT com> <4BC12044 DOT 6050806 AT huarp DOT harvard DOT edu>
Mime-Version: 1.0
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (windows-nt)
X-IsSubscribed: yes
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

Norton Allen <allen AT huarp DOT harvard DOT edu> writes:

> On 4/9/2010 5:56 AM, Paul Bibbings wrote:
>> If by "add a right-click context menu to the spinner" you intend to
>> retain the current problematic behaviour of the spinner but add the
>> context menu by way of avoiding the noted problems of cycling through
>> `uninstall', then I would, as a user, see that as an inconsistency.  I
>> would expect the two to be alternative ways of achieving the same thing
>> and regard the (presumably) silent difference to be a design flaw.  I may
>> be missing something, but I'm wondering how it is that, if the pass
>> through `install' can put in all the dependencies, continuing to
>> `uninstall' can't just take them out again?
>>   
> So what you want setup to do is remember whether a package was selected
> by the user or simply included to satisfy a dependency. Then when a
> package is deselected, the dependencies can be reevaluated.

Although I hadn't considered it fully when I wrote the above, this idea
certainly emerged as one that addresses a valid use case, the more I
thought about it.  Having said that, the more that I /have/ thought
about it, the more the set of valid use-cases seems to grow and the
whole thing starts to look horribly complex. Not that I'm wanting to
suggest that all `valid' (whatever that means) use cases /should/ be
accommodated. Like any maintenance project, if no-one's asking for it,
don't add it.

On a related note, it does seem that the current implementation is quite
geared towards the user simply making choices and then proceeding
straight to next. It's when a user changes their mind, or performs other
actions before proceeding to next that issues seem to arise.  For
instance, if I click on the view button and select `Not installed',
suppose I select a package that I don't have - for example (I'm trying
this now), aspell-dev 0.60.5-1.  Then, suppose I merely cycle through
the Views and come back to `Not installed'. aspell-dev is no longer in
the list, despite the fact that I have not done anything other than
change the view.  It is no more installed now than it was before. 

Regards

Paul Bibbings


--
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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019