Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Message-ID: <030901c0b410$4e843ee0$0200a8c0@lifelesswks> From: "Robert Collins" To: References: <3ABB6AC0 DOT 422CD04E AT yahoo DOT com> <20010323214739 DOT A17706 AT redhat DOT com> Subject: Re: setup wishes -- any volunteers Date: Sat, 24 Mar 2001 14:12:47 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 24 Mar 2001 03:07:10.0925 (UTC) FILETIME=[84A467D0:01C0B40F] ----- 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 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. 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 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. 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 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 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. Rob