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: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <3B8A5FAB.1030202@ece.gatech.edu>
Date: Mon, 27 Aug 2001 10:56:43 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
X-Accept-Language: en-us
MIME-Version: 1.0
To: cygwin-apps AT cygwin DOT com
Subject: Re: Updated setup.ini with descriptions, categories, and dependencies
References: <20010827004327 DOT A14852 AT redhat DOT com> <3B89E74D DOT 3060705 AT ece DOT gatech DOT edu> <20010827025736 DOT A15753 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

 >
 > Thanks.
 >
 > cgf
 >


Christopher Faylor wrote:

> On Mon, Aug 27, 2001 at 02:23:09AM -0400, Charles Wilson wrote:
>>cvs:
>> cgf:  ash cygwin perl tcsh zlib
>>
>> comments:  well, perl isn't actually *necessary* for cvs itself, it's 
>>only used by a few additional scripts.  Also, tcsh is not required at 
>>all.  OTOH, the cygwin build of cvs requires gdbm.  And crypt.  And 
>>'pr.exe' which is part of textutils.  Also, since the cvs source 
>>includes its own version of zlib, it doesn't really depend on the 
>>external zlib package.
>>
> 
> I wonder why the RPM version is so skewed from what you are relaying here.


well, there is a rational explanation for *most* of it:
1) gdbm: you can build cvs with gdbm as an option.  I chose to use that 
option; I suppose Red Hat did not choose to do so.
2) zlib: there's probably a config option for "use platform zlib" or 
some such.  I have not specified that option (if it exists) so my cvs 
build uses the internal zlib code.
3) crypt: the crypt() functions are built in to the linux kernel, so you 
don't really need an external package
4) tcsh, textutils: ???

> 
> However, if some part of cvs needs perl to operate then this is a dependency.


As far as splitting cvs into two packages, I don't have a problem with 
that.  (I've been wondering if we shouldn't split some of the library 
packages into, for instance, readline- and readline-devel- (or even 
"libreadline4" (containing only cygreadline4.dll and cyghistory4.dll), 
"libreadline5" (containing only cyg<*>5.dll and lib<*>5.a), "readline" 
(containing the executables and docs), and "readline-devel" (containing 
only the import libs and header files).  This new "readline" package and 
"readline-devel" package are un-major-versioned because you can only 
have ONE set of those installed at a time, corresponding to the most 
recent libreadline package.  But that's an awful lot of work; one thing 
at a time...)

> 
> 
>>jpeg:
>> cgf: ---
>> csw: cygwin
>> (category should be Graphics/Libraries, not miscellaneous)
>>
> 
> This is a difference from RPM.


>> sdesc: "A library of functions for manipulating JPEG image format files"
>>
> 
> As is this.


Right.  The RPM (a) doesn't specify an sdesc at all, and (b) is just 
plain wrong about the category.  Jpeg is not miscellaneous -- it's a 
graphics library.

Now, since the jpeg source code contains both the library and a few 
applications, perhaps Red Hat split it up into "libjpeg" 
(Graphics/Libraries) and "jpeg" (miscellaneous, contains the 
executables)  IMO, even *that* is marginal; I'd put BOTH into 
Graphics/Libraries.

> 
> My script didn't properly translate the jpeg -> libjpeg but I have rectified that.
> 
> I've made all of the changes you've mentioned.  I still wonder why RPM got some
> of them "wrong".

I hate to let you in on this secret, but RPMs -- Red Hat as well as 3rd 
party -- routinely get dependencies wrong. <g>  Usually by artificially 
requiring a higher version that is ACTUALLY required, forcing unneeded 
upgrades, but also by just plain leaving stuff out or including 
additional unnecessary "dependencies".

And of course, categorization is just a matter of opinion, anyway.

--Chuck