This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: Updated setup.ini with descriptions, categories, and dependencies
>
> 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