public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: cygwin-apps@cygwin.com
Subject: Re: [PATCH setup 00/14] Use libsolv, solve all our problems... (WIP)
Date: Sun, 14 Jan 2018 01:52:00 -0000	[thread overview]
Message-ID: <7a9e6a78-7342-063f-8c4b-a4b205fccf16@SystematicSw.ab.ca> (raw)
In-Reply-To: <032b0ecf-744d-b1bf-00c5-d3adaa2a4a02@cornell.edu>

On 2018-01-13 17:00, Ken Brown wrote:
> On 1/13/2018 5:55 PM, Ken Brown wrote:
>> On 1/13/2018 4:29 PM, Brian Inglis wrote:
>>> On 2018-01-13 12:56, Ken Brown wrote:
>>>> 2. We should probably remove, or at least reword, the dire warning about
>>>> accepting the default solutions.  I'm not sure we want to "strongly recommend"
>>>> the default solution over the other solution(s).  I guess what we really
>>>> want to
>>>> say is that we strongly recommend resolving the problems before continuing.
>>>
>>> For users who only run setup and use programs, a dire warning and strong
>>> recommendations are appropriate.
>>>
>>> Alternatives are to also remove all packages dependent on the package to be
>>> removed, or lastly, to remove only the requested package, leaving the
>>> installation inconsistent. Those alternatives would have to be presented to the
>>> user for selection, then executed.
>>>
>>> Anything else requiring the user to resolve would require a FAQ entry explaining
>>> what that meant, what diagnosis and actions would be required, and that would
>>> probably generate emails from users asking what they should do.
>>>
>>> Better to allow the solver to resolve issues and just let users choose
>>> straightforward alternatives, with the view of trying to keep the installation
>>> consistent, unless explicitly overridden, such as to test an alternative
>>> implementation of a dependency installed outside of setup.
>>
>> The current situation on the topic/libsolv branch is the following. Suppose A
>> requires B and the user asks to uninstall B.  They will get a problem report
>> showing two possible solutions:
>>
>> 1. Uninstall A.
>> 2. (default) Don't uninstall B.
>>
>> If they uncheck 'Accept default solutions' and select 'Next', they'll get a
>> warning that says "We strongly recommend that you accept the default
>> solutions.  Some packages may not work properly if you don't. Are you sure you
>> want to proceed?"
>>
>> This is misleading insofar as it implies that something bad will happen if the
>> user prefers to solve the problem by uninstalling A.  What is true is that
>> some packages may not work properly if the user answers 'Yes'.
>>
>> I think we should be able to find wording that is accurate while still making
>> it clear that we recommend going back and fixing the problem.  I don't yet
>> have a good candidate for that wording.
> 
> Something like the attached might do the job.

Just saying "Unsolved problems" does not tell the user what they did and what
impact it will have, and invites a FAQ entry for Setup - Unsolved problems.

Could we please be more explicit in the UI and the logs about the action being
taken and the impact: instead of "Unsolved problems" and "Some packages" maybe
something more like "uninstalling package U will break packages P1...", and
instead of "default solutions" maybe something more like "recommended actions"?

That shows and records the action and impact for diagnosis and remediation when
users do something unintended and need to undo it, changing the messaging from
the implementation model to the user's model, and giving users and maintainers
enough information to diagnose what will or did happen, and how to undo that.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

  reply	other threads:[~2018-01-14  1:52 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-31 10:53 Jon Turney
2017-05-31 10:53 ` [PATCH setup 04/14] Hoist pick() up to packagemeta Jon Turney
2017-05-31 10:53 ` [PATCH setup 05/14] Hoist uninstall up to Installer::uninstallOne() Jon Turney
2017-05-31 10:53 ` [PATCH setup 01/14] Opaque how PackageDepends is stored Jon Turney
2017-05-31 10:53 ` [PATCH setup 03/14] Hoist addScript() etc. up from packageversion to packagemeta Jon Turney
2017-05-31 10:53 ` [PATCH setup 02/14] Factor out reading installed.db Jon Turney
2017-05-31 10:57 ` [PATCH setup 09/14] Remove cygpackage class Jon Turney
2017-05-31 10:57 ` [PATCH setup 08/14] Change to using a libsolv pool for storing package information Jon Turney
2017-05-31 10:57 ` [PATCH setup 10/14] Remove packageversion class Jon Turney
2017-05-31 10:57 ` [PATCH setup 06/14] Hoist scan() up from packageversion to packagemeta Jon Turney
2017-05-31 10:57 ` [PATCH setup 07/14] Store package stability in class packageversion Jon Turney
2017-05-31 11:05 ` [PATCH setup 11/14] Drop in SolvableVersion as a replacement for packageversion Jon Turney
2017-05-31 11:05   ` [PATCH setup 12/14] Use solver to check for problems and produce a list of package transactions Jon Turney
2017-05-31 11:05   ` [PATCH setup 13/14] Download/checksum/install/uninstall what transaction wants Jon Turney
2017-05-31 11:05   ` [PATCH setup 14/14] Add obsoletes: support Jon Turney
2017-08-29 13:37 ` [PATCH setup 00/14] Use libsolv, solve all our problems... (WIP) Ken Brown
2017-08-30 21:47   ` Ken Brown
2017-09-01 15:01 ` Ken Brown
2017-09-02 16:57   ` Ken Brown
2017-09-05 13:34     ` Jon Turney
2017-09-05 18:40       ` Achim Gratz
2017-09-06  2:52         ` Ken Brown
2017-11-23 18:10           ` Jon Turney
2017-11-23 20:32             ` Ken Brown
2017-11-23 20:54             ` Achim Gratz
2017-09-08 18:54 ` Ken Brown
2017-09-11 20:40   ` Ken Brown
2017-09-13 19:17     ` Achim Gratz
2017-09-13 21:16       ` Ken Brown
2017-09-14 17:26         ` Achim Gratz
2017-09-14 20:46           ` Ken Brown
2017-09-15 19:24             ` Jon Turney
2017-09-16 16:21               ` Ken Brown
2017-09-19 12:24                 ` Ken Brown
2017-09-19 16:46                   ` Jon Turney
2017-09-19 16:58                     ` Ken Brown
2017-12-05 14:32             ` Jon Turney
2017-12-05 17:36               ` Ken Brown
2017-12-13 17:31               ` Ken Brown
2017-12-13 18:06                 ` Achim Gratz
2017-12-13 22:31                   ` Ken Brown
2017-12-14 14:12                     ` Ken Brown
2017-12-24 15:00                     ` Ken Brown
2018-01-09 13:25                       ` Jon Turney
2018-01-09 15:37                         ` Ken Brown
2018-01-09 15:49                           ` Ken Brown
2018-01-13 14:14                             ` Jon Turney
2018-01-13 19:56                               ` Ken Brown
2018-01-13 21:29                                 ` Brian Inglis
2018-01-13 22:55                                   ` Ken Brown
2018-01-14  0:00                                     ` Ken Brown
2018-01-14  1:52                                       ` Brian Inglis [this message]
2018-01-14  2:37                                         ` Ken Brown
2018-01-15 19:02                                 ` Jon Turney
2018-01-15 21:50                                   ` Ken Brown
2018-01-18 19:14                                     ` Jon Turney
2017-09-15 15:15   ` Jon Turney
2017-09-15 16:53     ` Ken Brown
2017-09-15 20:56       ` cyg Simple
2017-09-17 16:02         ` Ken Brown
2017-09-26 14:50       ` Jon Turney
2017-09-26 16:07         ` Ken Brown
2017-09-27 19:14           ` Jon Turney
2017-09-27 20:33             ` Ken Brown
2017-09-29 17:38               ` Jon Turney
2017-09-29 20:34                 ` Ken Brown
2017-10-02 14:07                   ` Jon Turney
2017-10-02 15:17                     ` Marco Atzeri
2017-10-04 14:43                       ` Jon Turney
2017-10-10 11:18                   ` Ken Brown
2017-10-10 15:49                     ` Jon Turney
2017-10-17 12:45                     ` Ken Brown
2017-10-17 18:47                       ` Jon Turney
2017-10-18 15:28                         ` Ken Brown
2017-10-18 15:57                           ` Ken Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7a9e6a78-7342-063f-8c4b-a4b205fccf16@SystematicSw.ab.ca \
    --to=brian.inglis@systematicsw.ab.ca \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).