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


Charles Wilson <cwilson@ece.gatech.edu> writes:

>> Would anyone please explain (in the FAQ) *why* you need to reinstall
>> the package *manually*?
>
> Because you manually screwed something up.

I don't understand.

> XEmacs is not a cygwin package.  Therefore, cygwin setup.exe doesn't
> know anything about XEmac's dependencies.

XEmacs?  I'm mainly asking because we get lots of bugreports for the
not-officially-part-of-cygwin LilyPond distribution, that I'm
offering temporarily.

I'm maintaining a partial mirror of Cygwin, and offer additionally
Guile and LilyPond.  When Guile (1.6?) is ready, it will hopefully get
into Cygwin.  I'm not sure if lilypond ever will, but the separate
repository we have now is not a grand solution either.  The setup.ini
is generated using the original setup.hints from (a mirror of)
cygwin.com.

When I'm doing test installations from scratch, it just works, and I
don't have any missing dependencies.  But somehow, it seems that
people that are upgrading, and maybe have an other/older version of
cygwin installed, miss out on some dependency.

I want it to work, and if all setup.hints are correct, it should work.
If not, I'd much rather bother the maintainer of a package, than tell
a user to resolve dependencies by hand.  I don't want to use XEmacs,
and I don't have a clue why it wouldn't use setup.exe, or why it would
not list its dependencies like it should.

> 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...

I think we should try to pressure^H^H^H^H^H^H^H^H kindly convince the
maintainers/distributers of such programs to offer a sane setup.ini
for their program.  It would be good not to get these questions,
except in case of a packaging bug.

> Well, we learn as we go.  Originally,
> libpng was one big package that contained everything
[..]
> 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....

Hmm.

> 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" ?

It means that setup.exe's handling of dependencies is broken and that
that we're in dire need of versioned pakcage requires: (like Debian
has) or file dependencies (arguably less user friendly but also works,
like Red Hat).  To take XEmacs as an example, when libpng got split,
it's setup.hint (assuming it tries to play nice) should have been
changed from

   requires: ... libpng ...

to

   requires: ... (libpng <= <orig version> | libpng2 >= 1.0.12-1) ...


I still don't think the user should have to deal with this.

> 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

That's silly.  If a dependency changes, the package number should be
increased.  Correctness is more important than bandwidth, if you're
short on bandwith, just don't run setup.exe too often.

> 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.

Indeed.

> 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"?

Hmm, that's why I have long (pre-setup.exe) wondered why Cygwin would
not adopt rpm (or dpkg, whichever), and plug in to those development
resourses.  Yes, I know about the mounting problem that would need to
be addressed, and setup is a nice gui interface, which seems to be all
important.  But at times like this, it seems on the one hand such a
shame that cygwin can only handle the simplest cases of dependencies,
and on the other hand it would be a shame to invest too much time in a
problem that has been solved in a number of different ways.

> And it STILL won't solve the "unofficial package" problem, like
> XEmacs...

No, but if the problem is solved technically, we could ask unofficial
packages to behave.  I hope (and want) the LilyPond package to behave
and play nice.

> Ya know, sometimes the user just has to use his brain...and noodle out
> the problem.

Yes, that would be nice :-)
Maybe we could have a FAQ entry: Would I need to keep my head on while
installing [Cygwin]?

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org


--
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]