Re: Welcoming Brian Dessent as setup maintainer

[Brian Dessent <brian at dessent dot net>]

Christopher Faylor wrote:

> I've asked Brian Dessent if he would like to become an official maintainer
> of setup.exe and he has graciously accepted.

On that note, I would like to start an open dialog about bugfixes and
features for setup.  As all of you know, things seem to move glacially
slow with development of setup.  Perhaps that's good in that we don't
surprise our users :) however it does mean that there is a lot that
could be improved.

The main thing I have been working on lately is a change that will
double check the user's choices after they are done selecting packages. 
If there are no unmet requirements, setup just moves on to the next
stage as normal with no change in UI.

If it finds anything missing, it adds another page to the wizard that
lists the missing packages and which packages depend on them.  There is
a checkbox at the bottom labeled "Install these packages to meet
dependences", and if the user just presses "Next" all the required
packages are added.  The user can also press "Prev" and modify the
selection, or if he's brave he can uncheck the box and continue anyway. 
If he does that he gets a stern popup that asks if he's sure he wants to
continue, given that breakage will likely occur.

Below is an example of what it looks like.  I set everything in category
"Base" to "Uninstall" and then pressed "Next" (!).

http://dessent.net/tmp/setup-depends1.png

If the user unchecks the checkmark at the bottom and attempts to
continue, he is met with this:

http://dessent.net/tmp/setup-depends2.png

I still need to do some polishing and I would certainly want to solicit
feedback from all of you and do testing before letting it anywhere near
users.  My hope with this addition is to catch any dependency errors
that cause broken installs and user frustration -- be it through setup
bugs or user error.

Here are some other things that I would like to address.  Please let me
know if you think they are good or bad ideas.

Bug Fixes / New Features
(in no particular order)
------------------------

- I still have not had a chance to review Dave Korn's
postinstall/preremove script.  I do know that there's no truly foolproof
way of handling this issue though.  Some postinstalls might depend on
packages that you're trying to upgrade, and would bomb if you removed
those files first.  There was a long mailing list thread on this a while
ago that basically came to the conclusion that there was no easy answer.

- A user reported a unique issue earlier today that deals with trying to
upgrade older packages.  If you have a package that is old enough that
it has fallen off the mirrors, and you don't have a copy in your local
cache, then setup treats it slightly differently since it doesn't have a
source for it.  This can result in not being able to even get the
current version selected.  I can reproduce this easily and I know the
part of the code that needs help (packagemeta::set_action()), so I hope
to arrive at something that works a little better in this situation.

- setup is already fairly cryptic, it does not help that there are
absolutely no help buttons.  We have to keep it as a single monolithic
executable (so no external help files), but I believe that we can still
add context-sensitive help that would display a popup "balloon" after
you click on the "?" and then click on the thing you want help with.

- setup should be able to save and restore its window position and
size.  This is a personal peeve of mine.  I know the whole
"resizeability" thing was a huge complicated issue back in the day.  I
have no desire to change how it acts out of the box, but I just think
that it should remember whatever size you make it.  This also applies to
all those annoying things like desktop shortcuts and so on.  Basically
it shouldn't pester you for the same stuff over and over; what you set,
it should remember.

- The user mode/system mode mount thing seems to be wearing out its
welcome.  Seems like for a lot of people, system mounts are the way to
go and there's no reason complicating it for them.  But there will still
be cases -- be it lacking admin permissions, or desire to support
multiple users -- where you still want user mounts.  So we can't just
rip it all out, but it does seem reasonable that we could first check
for admin privileges, and if they exist then assume system-wide mounts
for new installs.  Existing installs would keep whatever they're set to,
and we'd need some way for people that want to use user mode mounts to
easily do that - maybe a command line switch, or a setting in a file.

- If the user has entered by hand a mirror location or is using an
ancient mirror, it could really detract from their experience if they're
getting stale packages.  Setup should probably warn or gently prod the
user if it detects that the mirror they're using isn't on the cygwin.com
list.  (cgf pointed me towards this issue.)  Again, I'm sure there are
lots of people out there that are legitimately using mirror locations
not on the official list, so I'm thinking of something along the lines
of a warning message with an option to "don't ask me again", or at least
"don't ask me again unless I enter a new url that's also not on the
list".

- Users have requested the ability for setup to be able to work if
cygwin.com can't be contacted (for whatever reason) and that sounds like
a good capability to have.  As it is we store the last used mirror,
which would be enough.  But we could also store a local copy of the
mirrors list.

- Very minor cosmetic thing, but we should include a manifest with the
.exe.  With that one change you get the updated common controls that
were added in XP.  You can see this in the screen shots above actually,
I've been building it that way for a while now.  Now, I'm fully prepared
for the jokes about XP looking like fischer price ("My first OS!") but
it doesn't hurt to spruce up the appearance a little bit since that kind
of thing matters to a lot of people.  It's essentially a free change,
you just add the manifest and that's it, you don't have to maintain
anything.  I would of course want to test it on all the older 9x systems
but I'm fairly sure they degrade fine (the manifest I used was more or
less the boilerplate one from the SDK.)

- Accessibility and retooling the package selector.  This is a big one. 
I feel that the current method of choosing packages -- while very
effective once you know what you're doing -- is a little non-intuitive. 
FOr example, raise your hand if you fully comprehend the difference
between clicking in the "New" column and clicking on the "X" in the
"Binary" column -- and they don't always do the same thing.  In the
problem report mentioned earlier where the "current" version does not
have a source (as in a source for the binary package) it gets even more
screwy and illogical.  And then there is the thing where if you set a
package to a test version, the next time you run setup it will try to
put the "curr" version back, because it doesn't know any better.  I just
feel that we can do better.  I don't have any immediate ideas but I have
some things I want to try mocking up.

Obviously with this -- and everything I've mentioned so far -- we would
want community decisions and peer review about directions we take.  But
at the same time, we've had that situation for the last 'n' years and it
has resulted in setup being essentially the same, so I think it's
important to seriously consider trying to improve things.  As I said I
have some ideas that would be relatively non-invasive and still keep the
same spirit of how setup works now, but would make things a lot more
clear to the user, such as: which versions of a package are available,
the longer description of the package, how much disk space each package
will require, and so on.


---------

Okay, so that was a much longer and rambling post than I had intended to
make.  You must think I love hearing myself type.  If you have a short
attention span, allow me to summarize how I feel about this as follows:

*********************************************************************
** The current user experience of setup.exe is needlessly harsh,   **
** and I think we can improve that without _too_ much effort. It's **
** just that we're so used to it that we all know how it works and **
** its idiosyncracies.                                             **
*********************************************************************

(With extra special emphasis since I know nobody sits down to read a
long boring screed like this all the way through.)

The things I have mentioned above were for the most part things that I
care about as a user of setup or things that I've been actively looking
into.  Some of them were also mentioned to me by others like cgf.  I
welcome your comments about which ones you like or dislike, or other
things that you think would take setup in a new direction.

What I would like to keep out of the discussion, is the "why are we
using setup anyway when there's rpm/apt/pkgsrc."  Yes, I know they are
superior in many ways.  But Cygwin has its own unique requirements, and
so it will be a _significant_ undertaking to throw it all away and "just
slap something together."  For the time being, let's see if we can
concentrate on small incremental improvements to setup, and not the
"let's just go with rpm" thread.

Brian