This is the mail archive of the cygwin-apps@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: 1.5.14-1 cygwin1.dll could not be found


----Original Message----
>From: Dave Korn
>Sent: 07 April 2005 20:07

[Thread properly TITTAL'd, to coin a phrase]

>   Well, I have a crude patch going, and it's that time of night that I'm
> leaving the office and going home now[*], so here's what I've done so far,
> just in case anyone else wants to have a go and see if it works for them.

  Here's rev.1 of that patch.  I've avoided all the code duplication from
the cut-n-paste-coding of the previous patch by factoring out the repeated
bits into subroutines (and indeed by removing some slightly pointless
constructs like that "int e = 0; e +=" thing that was going on in the
try....catch clauses.  I've also removed the message boxes that I put in for
debugging.

  The following points however remain:

> 3)  There's no changelog entry!
> 
> 4)  I'm not sure how correct it is!  For instance, do I need to worry
> about whether the cygwin package is going to be an
> uninstall-and-reinstall or a replace-in-place?

  To which I may as well add:

5)  Do I really need to worry about putting return statements after calling
"LogSingleton::GetInstance().exit (1);" ?  There was a reference in there to
some kind of 'issue' with ::exit, but I haven't yet done an archive search
to try and understand what's going on - does anyone remember?

  I'm not so worried about 4) now.  There's nothing innate to stop a package
from being processed first by the uninstall, then by the replace-in-place
loop, and if the uninstall affected the flags in the packagemeta in such a
way that they passed the test (which I have now moved into
upgrade_if_needed), then it would indeed be first uninstalled and then
replaced in place.  However that's the way its always worked; I assume it is
implicitly protected against this by the behaviour of the various
pkg.installed and pkg.desired flags.

  Anyway it seems to do the job reasonable well, so if nobody has offered me
any of the requested-for comments by Monday a.m., I'll call it finalised and
resubmit it with a changelog entry.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Attachment: setup-save-cygdll-til-last-patch.diff
Description: Binary data


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