This is the mail archive of the cygwin-apps 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: call for testing of latest setup.exe snapshot


On Sun, 6 Aug 2006, Brian Dessent wrote:

> I've just uploaded <http://cygwin.com/setup/snapshots/setup-2.551.exe>.

Hi, Brian.  I meant to reply sooner -- sorry for the delay.  Thanks a lot
for doing this!

> If you had experienced any problems with previous versions please try
> this one and report if it solves your issue or not.
>
> The above is CVS HEAD as of this moment.  I committed several
> outstanding patches (sorry for the huge delay Igor!) and have tried to
> round up all or most of the remaining outstanding patches/reported
> problems below.  I wanted to put everything in one thread instead of
> continuing a bunch of individual threads.  Sorry if this breaks up the
> discussion too much.  (Of course there were many more things in the
> "feature request" pile but that is another matter.)

No problem with the delay -- as long as they got in... :-)  FWIW, I have
commit rights in the cygwin-apps repository, so in the future you can just
give me the go-ahead to commit and let me deal with the merge conflicts.

> http://www.cygwin.com/ml/cygwin/2006-05/msg00594.html
>   Null dereference in new_cstr_char_array.  This was already fixed in
>   CVS on 2006-03-14.
>
> http://cygwin.com/ml/cygwin-apps/2006-02/msg00124.html
>   Stray debugging messagebox removed.
>
> http://cygwin.com/ml/cygwin-apps/2006-02/msg00099.html
>   So, we have a couple of issues here.  Firstly, the bug/unintended
>   feature of -r causing the infinite retries until the file can be
>   written (if I understand correctly.)  Second the patch by Igor that
>   adds a dialog when trying to replace an in-use file.

Right.

>   Here is my opinion on the matter: I like the dialog idea, but I don't
>   think having "Abort" as an option is appropriate, as it will
>   potentially cause a really screwed up install, plus it was left
>   unimplemented in the patch submitted.  So let's just have two
>   options: "Retry" and "Replace on Reboot".  I know that this means we
>   can't use the stock "Abort/Retry/Ignore" dialog but I think it's
>   worth it for clarity.

Agreed on all points.  However, there is a technical issue here.  Stock
MessageBoxes come in many flavors -- there actually is a Retry/Cancel box.
There is no Retry/Continue stock box, unfortunately.

We can use the Retry/Cancel one, and perhaps play some games with the
WNDPROC of the MessageBox class to make "Cancel" look like "Replace on
reboot" (or "Continue", which I like better -- we can explain in the
MessageBox text that pressing "Continue" will require a reboot later), but
I'm not sure it'll work, and it'll be ugly.  Plus, I don't know that much
about the WNDPROC, so it'll take me a bit of time to get something like
this working.

OTOH, I can change my patch to use the Retry/Cancel box today, and add the
following to the text: "Pressing 'Cancel' will cause setup to use Windows
mechanisms for replacing in-use files.  It will be necessary for you to
reboot after setup completes."  I know, the label "Cancel" is evocative of
aborting the whole installation, but this functionality is so useful, IMO,
that I, for one, would put up with a little annoyance of a wrong label.
Changing the label in a way I've described above could be a later
enhancement.

>   After we have that, we should fix the tar extraction bug with -r.

Absolutely.

> http://www.cygwin.com/ml/cygwin-apps/2006-01/msg00190.html
>   Parsing of installed.db.  I don't really see that this matters a
>   whole lot but it's certainly silly to have setup trying to read
>   fields that don't exist so I applied this (with minor updates to
>   account for std::string changes.)

Well, the intention was to reuse that third field for something else
(package version locking, IIRC) once setup no longer cares about the
value.

> http://cygwin.com/ml/cygwin-apps/2006-01/msg00204.html
>   Package validation exception.  As I said in the thread, I dislike
>   the idea of pretending that invalid files don't exist without some
>   kind of error, and the specific case I was thinking of was a user
>   who downloads and installs in two separate steps.  If a file obtained
>   during the download step turns out to be corrupt/wrong size, then
>   during "install from local directory" it will simply be silently
>   omitted from the package list, which might be rather confusing if
>   it's something important.  Even if the automatic dependency checking
>   page flags a problem it is still not something the user can fix -- it
>   will say "select this package!" but that package does not exist to
>   be selected and cannot be installed anyway.

Well, we could pop up an informational message box if setup is not in
unattended mode (or write to the log if it is)...

>   Still, since I nor anyone else has come up with anything better, and
>   because an unhandled exception is pretty ghastly, I've applied
>   Igor's patch.  In the future I would like to augment this with a
>   warning of some kind if the user is in "Install from local
>   directory" mode, but I guess that will have to wait.

Right.

However, there was another issue in that thread (the inline patch).  It
seems that applying that will cause the code to be simpler, but I'm afraid
there's some little issue I'm missing.

> http://www.cygwin.com/ml/cygwin-apps/2006-03/msg00070.html
>   -p option to specify packages to add.  I think I must have missed
>   this patch the first time it was posted but I reviewed it here:
>   <http://www.cygwin.com/ml/cygwin-apps/2006-07/msg00008.html>
>   If the submitter can fix the minor points raised I think it's fine
>   for inclusion.

If the submitter is still around (if he's not subscribed to cygwin-apps
anymore, I can resend your original message to him).  Otherwise, I'd just
reindent and apply anyway, but it's your call.

> <I don't have a URL>
>   Background color issues.  These should have been fixed for some time,
>   but a newer snapshot was never made.
>
>
> Bottom line:
>
> If we can finish off the "Retry/Replace" file-in-use thing and assuming
> there are no reports of new issues with this snapshot then I think we
> can push out a release.

Sounds good.  If people are fine with the Retry/Cancel box, I can have a
new patch by the end of this week.
Thanks,
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"


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