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 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: <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 Content-Type: text/plain; charset=us-ascii 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: List-Subscribe: List-Archive: List-Post: List-Help: , 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 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