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
Message-ID: <3ABAD1AF.5B48810B@ece.gatech.edu>
Date: Thu, 22 Mar 2001 23:31:43 -0500
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
MIME-Version: 1.0
To: bkeener AT thesoftwaresource DOT com
CC: cygwin-apps AT sources DOT redhat DOT com
Subject: Re: setup wishes -- any volunteers
References: <VA DOT 000006e9 DOT 003b7799 AT thesoftwaresource DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Brian Keener wrote:
> 
> I'm not sure I totally understood this and it's probably because I know
> absolutely nothing about dpkg or rpm for that matter as to how they work.
> I wonder how these will tie into the current operation of setup.  Are
> each of these essentially a replacement for tar and how do they control
> the dependencies and packaging.  

see http://www.rpm.org/
http://www.rpmdp.org/rpmbook/node7.html  "An introduction to package
management"

> Take for example the way I sometimes use
> setup to update my packages.  Because of a slow internet connection via
> phone line I might use setup to download 3 or 4 packages one night and
> then download 3 or 4 more the next night as opposed to trying to install
> all of them from the internet in one night.  After I get all the packages
> I want then I will run setup and perform the install from local directory
> and install all the packages I previously downloaded.  

This use of setup is totally orthogonal to "package management".  You're
basically using setup.exe as a glorified version of wget, but setup
"knows" about the finite list of cygwin packages that it can be used to
download.

That's not what setup is for, altough you're welcome to use it that way.

> I would not expect
> the download to really control anything based on the categories and
> dependencies although the ability to select the packages based on the
> appropriate criteria would be a nice touch.

A "nice touch" for a glorified "downloader" program.  A necessity for a
true package management tool.

> I sort of thought of the
> dependencies and categories as an aid in allowing setup to select the
> appropriate packages for download and then later for install.

"download" is not really the issue here.  Setup works perfectly well
from a local collection of tarballs.  The issue is the following:

newbie A (alice) just wants to be able to ssh to her windows box.  She
uses the (current) setup.exe tool and installs the OpenSSH package.  And
that's all.  

Alice is stunned when 
  a) it doesn't work
  b) "Bob" tells her she also needs the "cygwin" package and the "bash"
package
  c) "Chris" tells her she needs the mount.exe program to control her
mount table
  d) "Dave" says she should just install EVERYTHING and stop
complaining.

Setup needs to understand these package dependencies, so that Alice can
get SSH to work in one try, downloading ONLY the minimum required
packages.  This is not a simple task.  For instance, did you know that:

the talk program in the inetutils package requires the ncurses package
(but the other programs in inetutils do not)

you can run openssh without having installed the zlib package, but you
can't build openssh unless you've also installed the zlib, regex, and
openssl packages.

cvs depends on gdbm

> How does the above scenario tie in with using dpkg or rpm.

It doesn't, really.  With RPM, for instance, you still need to
"download" all of the dependencies for a given package; rpm will tell
you what those dependencies are (and then die).  dpkg will tell you, but
will also download & install them for you as part of the same operation.

The point: your use of setup is a 'neat thing' but is not the primary
purpose of the tool.  However, none of the changes folks have been
discussing will prevent your use of the tool in that way.

--Chuck