To: cygwin@cygwin.com
From: Paul Bibbings <paul.bibbings@gmail.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@mail.gmail.com> 	<4BBE2F37.1060303@cygwin.com> <83y6gx330e.fsf@torus.sehlabs.com> 	<83tyrl32lq.fsf@torus.sehlabs.com> <4BBE886F.409@cwilson.fastmail.fm> 	<4BBE99F4.2080405@gmail.com> <877hoheypo.fsf@gmail.com> 	<4BC12044.6050806@huarp.harvard.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (windows-nt)
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

Norton Allen <allen@huarp.harvard.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