This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: missing file FOO.dll


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]