Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Message-ID: <3C76FFD6.4050108@ece.gatech.edu>
Date: Fri, 22 Feb 2002 21:35:02 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
MIME-Version: 1.0
To: Bob Batey <robert_batey AT agilent DOT com>
CC: cygwin AT cygwin DOT com, tc _chat <tc_chat AT cvuxa DOT cvs DOT agilent DOT com>
Subject: Re: unable to locate CYGINTL.DLL dependency
References: <3C75594A DOT B1297364 AT agilent DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Bob Batey wrote:

> Hi,
> 
> The bug "UNABLE to LOCATE CYGINTL.DLL" (see Jan. 21, 2002 bug report
> from Marino Stramare) still surfaces.  The origin of this bug is when
> one doesn't install gettext (from the contrib).  Now seeing that some
> people might want to make their own CD roms, I expect core dependences 
> should NOT depend on contributed packages.  Seems that can be the source
> of this, since I experienced it long after it was reported.  


We're still working the kinks out of the "dependency issue".  Setup now 
supports them -- but not all of the existing packages accurately specify 
their dependencies for setup to use.  Also, some folks installed prior 
to the current setup.exe, and (according to one of today's threads) 
there may be a "final package selected not installed" bug...so yeah, 
there are some kinks.

We'll get there.

 
> As a solution, I wonder if you can put the gettext package in the
> appropriate "latest" directory?  Seems like a reasonable thing to
> do.  And there should be some hint in the vim package directory as
> to this dependency.


As already pointed out, vim's setup.hint / setup.ini entry already 
specifies that dependency -- so I'm not sure why your installation 
missed it.  Also, moving "gettext" from the contrib to the latest 
directory would not have solved that problem

However, I think that the "contrib" vs "latest" distinction is 
meaningless.  We shouldn't destabilize things by moving packages around 
for purely cosmetic reasons(*).  [this is a change from my previous 
opinion].  "latest" v. "contrib" was a historical division, when 
"latest" meant "inherited from B20.1, maintained by cgf, dj, corinna, 
..." and "contrib" meant "new contributions from non-RH employees".

But that has gone away.  I maintain bzip2, the autoconf(wrapper), 
automake(wrapper), ncurses, and libtool* packages in "latest", but also 
many packages (incl. gettext) in "contrib".  Some of Corinna's packages 
are in "contrib".  Some packages that are of only esoteric use are in 
"latest", but others that many people may consider core are in 
"contrib".  It's a difference without a distinction.

(*)
In the best of all worlds, we would reorganize the mirrors so that there 
were only the following two top-level directories (as far as setup.exe 
was concerned):

   cygwin/supported
     [contains everything currently under "latest" and
     "contrib", as well as the eventual "XFree86"
     setup-installable packages]

   cygwin/unsupported
     [I think we need a place for folks to just say "here: I ported this 
software to cygwin, and created a setup-installable package out of it. 
Here's the .tar.bz2 and the -src.tar.bz2.  But I don't want to maintain 
it.  I have a libiconv package like this: I've ported it, but am 
unwilling to support yet another package.  These unsupported packages 
could STAY in the unsupported dirctory, and be in the "Unsupported" 
setup category, but if somebody wanted to "adopt" it then it could be 
moved into the "supported" directory.  That way, folks who wanted to dl 
and burn to CD only the "core" cygwin could get it by grabbing the 
"supported" dir.

This pair of dirs has real meaning.  The current "latest" vs. "contrib" 
doesn't.

But I am not advocating this wholesale reorganization -- because moving 
that much stuff around in the dir structure could seriously overload the 
mirror system.  There's also the problems that occured when we moved 
ncurses around -- setup got confused. We don't yet know (for sure) 
whether the soon-to-be-released new version of setup will gracefully 
handle packages moving around.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/