Updated setup.ini with descriptions, categories, and dependencies

Charles Wilson cwilson@ece.gatech.edu
Mon Aug 27 07:56:00 GMT 2001

 > Thanks.
 > cgf

Christopher Faylor wrote:

> On Mon, Aug 27, 2001 at 02:23:09AM -0400, Charles Wilson wrote:
>> 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...)

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

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


More information about the Cygwin-apps mailing list