Mail Archives: cygwin/2002/05/31/10:57:42
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/
- Raw text -