This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: setup wishes -- any volunteers

----- Original Message -----
From: "Christopher Faylor" <>
To: <>
Sent: Saturday, March 24, 2001 1:47 PM
Subject: Re: setup wishes -- any volunteers

> 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.

Probably :]

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

yes - I agree completely. The reason I suggest an dpkg backend is that
it has _the same_ goal. dselect is text-only, but its completely data
driven which means making it gui is trivial.

> So, to use Chuck's example, when you click on inetutils, you
> automatically also select cygwin and ncurses for
> 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
> checkbox.

Or perhaps a "Warning - you have a missing dependencie foo. Here are
your options to resolve it (give list of possible packages with a
default selected). If the user selects none, then it's downloaded
irrespective of dependencies.

> 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.

Agreed. (Note that I never brought up end user understanding). They
should just see an interface and use it...

> My desire is to implement the two objectives as quickly as possible.
> That is why I was advocating creating simple text files to control
> 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.

Ok. I'll try something different.... I'll see if I can rip _just the
dependency logic_ out of a well known dependency driven system and get
it working in some fashion with setup.exe.

> So, again, I am not adverse to exploring RPM.  It has been a goal
> we first went live with the new scheme almost a year ago.  I just
> see how we can do this quickly.  It will require repackaging
> 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

Agreed. A point that's been missed above though: When a windows user
sets up a program they expect to see configuration dialogs ("What
username should service foo run as"). These are completely missing at
the moment. I know next-to-nothing about rpm's internals so I cannot
authoritatively comment... but whatever ends up behind the scenes needs
to be able to pop up such dialogs, and only the ones relevant to the
software being installed. So when I choose sshd (as opposed to ssh) in
the software list, I want a configuration box to comeup after it's
downloaded asking me what user to run the service as.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]