This is the mail archive of the
mailing list for the Cygwin project.
Re: Welcoming Brian Dessent as setup maintainer
- From: Brian Dessent <brian at dessent dot net>
- To: cygwin-apps at cygwin dot com
- Date: Tue, 03 May 2005 15:30:42 -0700
- Subject: Re: Welcoming Brian Dessent as setup maintainer
- References: <md5:18B2AEDE38D9A5170947883E87E8B8B6>
"Gary R. Van Sickle" wrote:
> I'm not sure that is a precondition. Cygwin setup could very easily be
> packaged up with InnoSetup into a single downloadable exe, but it would be a
> regular Windows installer, and setup.exe and any number of support files it
> might require could be installed just like any other application. In fact,
> it seems to me that even it did stay a single exe, having a regular
> installation process like this would be good, if only to eliminate the
> question of "where do I put setup.exe?"
> Adding HTML help, when it's a separate file anyway, is dead simple.
Another possibility might be to embed the .chm or .hlp file in the .exe
as a resource. I don't know if that's feasible or not.
Still, the context sensitive help would go a long way, and there is a
manual in html that they can refer to online.
> Many of the new programs I've installed recently ask the very similar
> question of "Do you want to install for all users of this computer, or just
> the current user?", albeit usually for different reasons, so I don't see
> anything fundamentally wrong with the status quo. I think simply clarifying
> this functionality (along with the DOS/UNIX mounts etc) and/or not asking it
> every time (as I believe others may have already suggested) would
> essentially solve any current issues there (UI issues anyway).
The problem is joe user installs "for me" and then tries to install a
service like sshd, cron, etc. And it naturally fails because SYSTEM
doesn't see any mounts. So one or more of (setup.exe, cygrunsrv,
/usr/bin/foo-install-script) probably needs to do more sanity checking
in those cases.
> I still maintain that the whole "Select a mirror" thing is not something
> that should normally be user-visible. By far the most common use case is
> the user trying to update their current Cygwin installation with updated
> and/or new programs, and they absolutely don't care which mirror they're
> coming from. They certainly shouldn't be expected to know which ones are
> current, nor which ones are "better" than the others, nor which are
> currently available, because they simply won't know. Some automatic means
> of deciding this stuff should exist, and be the default way mirror selection
> works. "Install from a specific mirror" or whatever can require the user to
> press another button or two, or set an "Options" checkbox somewhere, as it
Ahh but that's been in place for something like 3 years already. The
script is here:
The mirrors.lst and the list on the website are generated by a perl
script that polls them all regularly and drops any that don't respond or
have a setup.ini that's more than a few days stale. Any mirror on the
list is guaranteed to be good.
The reason why users *do* need to know which mirror they are using is
that currently the local cache is keyed to the url. (As I am sure you
very well know.) So if you frequently hop around mirrors, you get
duplication in the cache. I would imagine that most users want the
control of it to the extent that they can find a site they like a stick
with it -- I know that's what I do, and I'd be very hostile if suddenly
setup.exe did the picking for me.
> I was never able to get this to fully work, as the resource compiler wasn't
> able to handle manifest resources. Are you sure that this is really working
> for you? I was fooled for a while, because if you have the manifest file in
> the same directory Windows will use that and it will work fine, but move the
> exe and it suddenly is back to the non-themed olde-tyme controls. (Maybe
> another reason to go to an InnoSetup installer?)
Yes, it's in a different directory. Just to veryify I tried renaming
the manifest and it works fine. I think windres has progressed since
you last tried. I was actually going to post those patches just now,
and a compiled .exe, so that people can test that.
> I think I recall doing some not-insignificant work on the SDK boilerplate,
> for reasons that are lost to the fog of time. I can dig that up if you
> think you might be able to make use of it.
The only thing that gave me pause was the "version" attribute of the
assemblyIdentity tag, which is supposed to be in "n.n.n.n" format. I
just set it to 18.104.22.168 and see no reason why it would need to be
dynamically updated. It's not like the file version resource, and as
far as I know nothing really reads that.
> One thing you didn't explicitly state, but is implied by many of your
> points, is that the UI and business logic badly need to be disentangled.
> Max, myself, and others have picked away at that over the years, but last I
> checked there still was not a clear division.
I think it would be fabulous if setup.exe was just a gui that
manipulated a list of which packages you wanted, and there was some
other back-end that did the downloading, installing, and removing.
(Kind of like the divide between dselect and apt/dpkg in debian world.)
But I'm also a realist and I know that it will take a lot of work to get
there from here. I'd rather get the low hanging fruit of tangible UI
improvements. It beats stagnation. As far as big picture, that's a
really tough question, as to whether to try to hang in there and
laboriously split setup.exe into respective sides of the fence, or pick
up trying to port one of the other package managers. That's certainly a
good discussion that the Cygwin project will need to have. But for just
right now, I think there some things that can be done to ease the
suffering of newbies trying to grok setup.exe.