Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3CF78EB7.8080506@ece.gatech.edu> Date: Fri, 31 May 2002 10:54:47 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Jan Nieuwenhuizen CC: cygwin AT cygwin DOT com Subject: Re: missing file FOO.dll References: <4 DOT 3 DOT 1 DOT 2 DOT 20020529142614 DOT 02615830 AT pop DOT ma DOT ultranet DOT com> <87k7pka61q DOT fsf AT peder DOT flower> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jan Nieuwenhuizen wrote: > > Would anyone please explain (in the FAQ) *why* you need to reinstall > the package *manually*? Because you manually screwed something up. XEmacs is not a cygwin package. Therefore, cygwin setup.exe doesn't know anything about XEmac's dependencies. Imagine I installed a barebones cygwin, and then installed cygwin-XEmacs from xemacs.org. Well, I happen to know that cygwin-XEmacs requires cygpng2.dll cygjpeg6b.dll cygncurses6.dll cyggdbm.dll cygz.dll cygtiff3.dll cygXpm-noX4.dll and oh yeah cygwin1.dll Okay, so I'm missing a number of packages -- which ones? I know, I'll ask the (cygwin) list! So as long as "other sites" porovide programs that run on the cygwin platform, we'll get these questions... Now, in this particular case "XEmacs was working and then I upgraded cygwin -- and now it's broken". Well, we learn as we go. Originally, libpng was one big package that contained everything -- headers, docu, static lib, import lib, DLL. Later we got smart: and split things up inte separate packages -- so that, for instance, the libpng2 package (contains just /usr/bin/cygpng2.dll) libpng10 package (contains just /usr/bin/cygpng10.dll) libpng12 package (contains just /usr/bin/cygpng12.dll) can all coexist. This was not the case, pre-split. So, I had the "original" libpng package installed (which contained cygpng2.dll among other things). XEmacs works. Then, I upgrade libpng -- to the version that is current today. The new version doesn't contain cygpng2.dll -- in fact it contains only documentation, but "requires" libpng12; setup automatically figures that out and installs it, as well. So now, I have new libpng package (which contains docu) libpng12 package (which contains cygpng12.dll) Uh oh, nothing contains cygpng2.dll.... Since I have nothing "official" that has updated its requires list to need libpng2 (the new home of cygpng2.dll) -- therefore I don't automatically install that package. How is setup supposed to know that I have XEmacs installed and it needs "the package which contains cygpng2.dll" ? Worse, assume that I had previously installed the official cygwin package of ghostscript. Even if Dario has updated his setup.hint to now require the libpng2 package, I won't pick up that changed dependency when I run setup to update libpng and (say) autoconf. (I'm assuming that 'ghostscript' didn't increment its own version number -- because ghostscript itself didn't change -- but that Dario merely changed the requires: line in ghostscript's setup.hint so that new installs would get the 'correct' libpngish package) However, folks who installed ghostscript BEFORE the rearrangement/setup.hint-correction -- like me -- will be in the same "where'd cygpng2.dll go?" boat when we update our libpng package. I mean, we could have setup do the following: 1) look at all currently installed packages 2) check the requires: line of the corresponding packages in the just-downloaded setup.ini 3) if any requirements for currently installed packages are missing, add those (new) requirements to the default "to be installed" list. But, that's silly: what if MY installed version of 'foo' does NOT require 'bar', but the current version of 'foo' DOES rquire it? I don't *need* to install 'bar' unless I install the new 'foo'. setup.exe can't tell if changed requirements: lists are due to a) the maintainer of the required package changed his packaging structure (libpng-->libpng + libpng2 + libpng2-devel), or b) the new version of the requiree package has a new dependency that the old version did not have We could have per-version requirements: in setup.hint...but then we still need to add the three steps outlined above to setup's algorithm. Is all that worth it? If so, we have scarce programmer resources: what is the priority of per-version requirements: and extra patermalistic setup.exe behavior, compared to "setup crashes on XP"? And it STILL won't solve the "unofficial package" problem, like XEmacs... Ya know, sometimes the user just has to use his brain...and noodle out the problem. Without adding AI and (cygwin-packaging)historical knowledge to setup.exe -- as well creating a complete database of all possible programs Joe Schmoe might install, from whatever site on the net using whatever method those unofficial packages desire -- we can't solve these problems for every user. > It seems to me that there's a bug in one of the package's setup.hints, > in that it doesn't list some dependency. As I explained, XEmacs doesn't HAVE a setup.hint. > Either that, or the > installation is broken, or there's a strange bug in some popular > version setup.exe. No, there was a strange bug in our original packaging of some libraries -- libpng, ncurses, etc. -- which has since been fixed, but some packages still depend on the "pre split" packages. Once those are flushed frpm the pipeline, all will be well, except for unofficial programs like XEmacs. --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/