Re: setup wishes -- any volunteers

[Christopher Faylor <cgf at redhat dot com>]

I don't know if we are starting to stray from my original wants
or not but let me just bring things back to basics, if I can.

Most users of setup utilities on Windows are accustomed to the idea
of something which provides them with categories of setup.  Usually,
this is something like "Typical", "Full", or "Custom".  Hopefully
everyone knows exactly what I mean by this.

Personally, I never use "Typical" or "Full".   I use "Custom".

A typical "Custom" installation presents the user with a series of
choices like:

[]	Editor			4MB
[]	Additional Fonts	.5MB
[]	Remulac Adaptor		15MB
[]	MPEG Seinfeld Videos	215GB

When you click on the []'s above you get to view individual choices.
So, for example, in the above example, when you click on the "MPGEG
Seinfeld Videos" you could choose only the episodes that you like
and cut down on the whopping 215GB.

I'm advocating that Cygwin present a "Custom" style interface.  I think
this is clear.  What isn't clear in Cygwin is exactly what the
appropriate categories are.  I started to come up with categories but
found that some packages fall into multiple categories.  I think I
remember seeing something similar with apt.  When you click on a program
in one category, and move on to a new category, you might find that
program there, too, already checked.

So, it shouldn't be a big deal, conceptually to provide categories.  The
package maintainer could just provide a file in the directory on
sources.redhat.com with various descriptions.  These could end up in
setup.ini and setup.exe could sort and display things as appropriate.

I think that this would be an invaluable tool for a user.  It should
also be pretty intuitive for anyone who uses Windows.

The above is a would be nice.  What I think is essential currently is a
simple dependency scheme.  Again, this could be controlled by files in
the directories which just list any dependencies that a given package
has.  For now, I don't want to worry about the dependencies of the
sources, though, just the binaries.

So, to use Chuck's example, when you click on inetutils, you
automatically also select cygwin and ncurses for download/installation,
if they are newer than what is on your system.  If this dependency
is not useful for some people then maybe we can include a "use dependency"
checkbox.

With dependencies, when you download inetutils, you'll get everything you
need to run it and won't be stunned to see a "Cygwin1.dll not found"
message.

Since setup.exe is a GUI it doesn't matter a fig if the underlying
mechanism for unpacking packages is tar, rpm, cpio, apt, or cat.
There is no reason that a user will have to know anything about RPM
unless they are doing something "by hand".  I don't want to worry
about power users who disdain using setup.exe having to learn new
things.  That isn't a goal for setup.exe.

My desire is to implement the two objectives as quickly as possible.
That is why I was advocating creating simple text files to control what
needs to be done.  We see people in the Cygwin mailing list suffering
from confusion as to what they should download and what they are
downloading on an almost daily basis.  I think that we need to do
something fast.

The existence of a FAQ is not the answer.  That trick never works.  We
have a pretty good FAQ in Cygwin.  How often do we have to point people
at it?  Actually, to some degree I've always found the existence of a
FAQ to almost be an admission of failure.  There shouldn't be any
"Frequently Asked Questions".  The program should work the way that a
user wants it to work.  When the program is started the reaction should
be "Oh! I see." rather than "What the heck?"

This isn't of course a feasible end result for any program.  There are
two many different people with different levels of skill and different
expectations.  I've seen people internal to Red Hat complain that the
current setup.exe is confusing.  My reaction to this is "What the heck?"

However, I think that if we add dependencies and categories we will be
taking a giant step towards making setup more understandable by
everyone.  IMO, we will transition quickly from "I just want to use
baaasssshhhhhhhh." to "Why is it then whenever I click on bash it
downloads Cygwwwwwwwwiiiiiiinnnnnn???  I don't WANT Cygggggwwwwwinnnnn."

So, again, I am not adverse to exploring RPM.  It has been a goal since
we first went live with the new scheme almost a year ago.  I just don't
see how we can do this quickly.  It will require repackaging everything
in latest and contrib and that isn't a small task.

If/when we do go to RPM, I hope and expect that the end user will see
no change in the setup.exe interface.  They shouldn't have to know
what an RPM file is any more than they have to know what at .tar.gz
file is now.

cgf