Re: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take))
Christopher Faylor wrote: Otherwise, MaxB has disqualified himself from doxygen package maintainership, I would to appeal this, please, because I do not believe it is fair to censure me for a misunderstanding that I have explained and apologized for. The fact that a few words of mild intention can be misinterpreted and seed an accidental high tension mess has been amply well demonstrated on the cygwin list recently, in the CGF/GRVS thread. Max.
Re: [patch] setup dependency fix, was Re: setup.exe problem with selecting curr radio button
Brian Dessent wrote: Brian Dessent wrote: It may take me a while to comprehend the dependency code, but bugzilla-ed for now. Here is, I believe, a fix to the problem. Each packagemeta object has a Ping... Somehow, I missed that email the first time around. I've just found it in the archives. I'll take a look at it ASAP. Max.
RE: [patch] setup dependency fix, was Re: setup.exe problem with selecting curr radio button
Original Message From: Max Bowsher Sent: 03 May 2005 13:07 Brian Dessent wrote: Brian Dessent wrote: It may take me a while to comprehend the dependency code, but bugzilla-ed for now. Here is, I believe, a fix to the problem. Each packagemeta object has a Ping... Somehow, I missed that email the first time around. I've just found it in the archives. I'll take a look at it ASAP. Max. While you're at it, would you like to take a look over http://cygwin.com/ml/cygwin-apps/2005-04/msg00149.html [PATCH] Uninstall .dll last, reinstall first - final version as well? cheers, DaveK -- Can't think of a witty .sigline today
Re: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take))
Max, no - you have not disqualified yourself in my eyes. And therefore, you should be the new doxygen owner/maintainer if you want it that badly. I also think that we should put this issue finally to rest, stop pouting and get on with life! greets, H. Max Bowsher wrote: Christopher Faylor wrote: Otherwise, MaxB has disqualified himself from doxygen package maintainership, I would to appeal this, please, because I do not believe it is fair to censure me for a misunderstanding that I have explained and apologized for. The fact that a few words of mild intention can be misinterpreted and seed an accidental high tension mess has been amply well demonstrated on the cygwin list recently, in the CGF/GRVS thread. Max.
Re: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take))
On May 3 13:02, Max Bowsher wrote: Christopher Faylor wrote: The fact that a few words of mild intention can be misinterpreted and seed an accidental high tension mess has been amply well demonstrated on the cygwin list recently, in the CGF/GRVS thread. So you're comparing your specific situation with Gary's years long history of adding useless comments to cgf's postings in the Cygwin ML? I don't think that's the same and I don't think that's a convincing argument at all. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take))
On Tue, May 03, 2005 at 04:51:46PM +0200, Corinna Vinschen wrote: On May 3 13:02, Max Bowsher wrote: Christopher Faylor wrote: The fact that a few words of mild intention can be misinterpreted and seed an accidental high tension mess has been amply well demonstrated on the cygwin list recently, in the CGF/GRVS thread. So you're comparing your specific situation with Gary's years long history of adding useless comments to cgf's postings in the Cygwin ML? I don't think that's the same and I don't think that's a convincing argument at all. Big ditto, but any further discussion on this should go to cygwin-talk. It's certainly not valid here. Puzzling analogies aside, if maxb wants to be the new doxygen maintainer, I'll withdraw my objections. cgf
Re: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take))
Corinna Vinschen wrote: On May 3 13:02, Max Bowsher wrote: Christopher Faylor wrote: The fact that a few words of mild intention can be misinterpreted and seed an accidental high tension mess has been amply well demonstrated on the cygwin list recently, in the CGF/GRVS thread. So you're comparing your specific situation with Gary's years long history of adding useless comments to cgf's postings in the Cygwin ML? I don't think that's the same and I don't think that's a convincing argument at all.= I was not aware of the history you refer to (I've been skimming subjects and reading only selected threads on the cygwin ml for a long time now), and was just using it as an isolated example of messages being interpreted in a more inflammatory tone than they were intended, reaching quite drastic end results. Max.
RE: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take))
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Corinna Vinschen Sent: Tuesday, May 03, 2005 9:52 AM To: cygwin-apps@cygwin.com Subject: Re: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take)) On May 3 13:02, Max Bowsher wrote: Christopher Faylor wrote: The fact that a few words of mild intention can be misinterpreted and seed an accidental high tension mess has been amply well demonstrated on the cygwin list recently, in the CGF/GRVS thread. So you're comparing your specific situation with Gary's years long history of adding useless comments to cgf's postings in the Cygwin ML? Ahem, yeah, let's make that: ...Gary's years long history of taking Chris to task for his years-long history of uncalled-for snotty comments. Surprised Chris himself didn't keep you honest there. -- Gary R. Van Sickle
Re: [patch] fix for the proxy port preference not being saved
Brian Dessent wrote: This is the much-requested fix for the problem of not saving the proxy port. I had always expected this was some kind of trivial bug that just needed a quick fix, but I was incorrect. It was much more subtle than I gave it credit for. Essentially, save_dialog() is called any time a window message is received that indicates something has changed in the dialog, and the value is copied from the dialog into local variables. When setup terminates, these values are correctly saved to /etc/setup/last-connection, and properly read upon startup the next time. The problem was that when load_dialog() runs to ostensibly restore these saved values, it first sets the net_proxy_host value - but this causes a window message to be dispatched, which results in save_dialog() being called. Since load_dialog has not yet had a chance to restore the proxy port setting, save_dialog reads the value of 0 and replaces the value of net_proxy_host with 0. Seems simple enough in hindsight, but by the time I realized what was going on I had been single stepping through disassembly in user32.dll because I was convinced that the win32 call to SetDlgItemText() was clobbering adjacent memory locations. Silly me... Thankyou! A very nice piece of debugging. Committed, with the minor tweak of moving the initialization of the new boolean actually happens. I'm inclined to merge this change over to the release branch and actually release it. Max.
RE: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take))
[snip] So you're comparing your specific situation with Gary's years long history of adding useless comments to cgf's postings in the Cygwin ML? Ahem, yeah, let's make that: ...Gary's years long history of taking Chris to task for his years-long history of uncalled-for snotty comments. Surprised Chris himself didn't keep you honest there. Enough! :-) I held that thread up as an example of a misunderstanding creating a mess. Let's agree that misunderstandings are unfortunate, and not spread the mess around! Max. I could not agree more, Max. Misunderstandings are indeed unfortunate. Misrepresentations are something else entirely. FWIW, I fully support your stance that your unilaterally-imposed disqualification was unwarranted. At the same time, it's not difficult to understand Hans' consternation and reaction to the situation. Doxygen is a very useful package, and it would be sad for the Cygwin immune system to reject its inclusion on the basis that somebody did too much work. -- Gary R. Van Sickle
Re: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take))
On Tue, May 03, 2005 at 11:53:44AM -0500, Gary R. Van Sickle wrote: -Original Message- From: cygwin-apps-owner GROUPIE cygwin KOOK com [mailto:cygwin-apps-owner GROUPIE cygwin KOOK com] On Behalf Of Corinna Vinschen Sent: Tuesday, May 03, 2005 9:52 AM To: cygwin-apps GROUPIE cygwin KOOK com Subject: Re: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take)) On May 3 13:02, Max Bowsher wrote: Christopher Faylor wrote: The fact that a few words of mild intention can be misinterpreted and seed an accidental high tension mess has been amply well demonstrated on the cygwin list recently, in the CGF/GRVS thread. So you're comparing your specific situation with Gary's years long history of adding useless comments to cgf's postings in the Cygwin ML? Ahem, yeah, let's make that: ...Gary's years long history of taking Chris to task for his years-long history of uncalled-for snotty comments. Surprised Chris himself didn't keep you honest there. http://cygwin.com/acronyms/#PCYMTNQREAIYR And, again, further discussion in this vein should go to cygwin-talk, please. cgf
Re: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take))
On Tue, May 03, 2005 at 12:26:20PM -0500, Gary R. Van Sickle wrote: FWIW, I fully support your stance that your unilaterally-imposed disqualification was unwarranted. At the same time, it's not difficult to understand Hans' consternation and reaction to the situation. Doxygen is a very useful package, and it would be sad for the Cygwin immune system to reject its inclusion on the basis that somebody did too much work. I think this subject is closed: http://sources.redhat.com/ml/cygwin-apps/2005-05/msg00011.html It's now time to move on to the actual work of getting the new version of doxygen into the cygwin release. cgf
Re: Counter-ITP of doxygen (was: Re: Please upload: doxygen-1.4.2_20050410-1 (n'th take))
On May 3 12:26, Gary R. Van Sickle wrote: FWIW, I fully support your stance that your unilaterally-imposed disqualification was unwarranted. At the same time, it's not difficult to understand Hans' consternation and reaction to the situation. Doxygen is a very useful package, and it would be sad for the Cygwin immune system to reject its inclusion on the basis that somebody did too much work. As usual you're off the point. Anyway, please move over to cygwin-talk. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Welcoming Brian Dessent as setup maintainer
I've asked Brian Dessent if he would like to become an official maintainer of setup.exe and he has graciously accepted. So, we now have two people who can approve and apply patches to setup.exe and make new setup.exe releases. Welcome, Brian, and many thanks for volunteering to help out with setup.exe. cgf
Re: [PATCH] Uninstall .dll last, reinstall first - final version
Dave Korn wrote: Well, it builds, and it works, and I've tested it by rolling an installation back-and-forth across quite a large update (the difference between my local mirror set up last september and an up-to-date mirror), which I could do with the old setup and see things fail when it removed the cygwin dll early in the uninstall, and which worked fine with the patched version because it saves the dll until last, and nobody actually has any comments, but I've cut out the unnecessary return-an-early-abort-indication bit now that I'm convinced that LogSingleton::exit doesn't return. So I'd call that done for now. Here ya go! The problem with this is it special cases the cygwin package. Whilst undoubtably this is the one thing that almost everything depends on, there are other dependency issues which this does not touch. It is definitely valuable to have the section of code causing the problem pinpointed, but I think what we should do instead is to break out the uninstallation phase into two seperate passes: 1. Run preremove scripts 2. Actually remove files. This is still not perfect, but should resolve the majority of issues, and not just relating to the cygwin package itself. Max.
RE: [PATCH] Uninstall .dll last, reinstall first - final version
Original Message From: Max Bowsher Sent: 03 May 2005 19:55 The problem with this is it special cases the cygwin package. Whilst undoubtably this is the one thing that almost everything depends on, there are other dependency issues which this does not touch. It is definitely valuable to have the section of code causing the problem pinpointed, but I think what we should do instead is to break out the uninstallation phase into two seperate passes: 1. Run preremove scripts 2. Actually remove files. This is still not perfect, but should resolve the majority of issues, and not just relating to the cygwin package itself. Okeydoke, I'll look at it. I took the approach I did because it seemed like the least-invasive approach and thought it would catch at least some of the worst cases. I don't _suppose_ leaving the uninstall files present while running subsequent preremove scripts should affect anything, but it's certainly a larger operational change. Anyway, I'll drop a line back when I've got a new patch to try. cheers, DaveK -- Can't think of a witty .sigline today
Re: [PATCH] Uninstall .dll last, reinstall first - final version
Dave Korn wrote: Original Message From: Max Bowsher Sent: 03 May 2005 19:55 The problem with this is it special cases the cygwin package. Whilst undoubtably this is the one thing that almost everything depends on, there are other dependency issues which this does not touch. It is definitely valuable to have the section of code causing the problem pinpointed, but I think what we should do instead is to break out the uninstallation phase into two seperate passes: 1. Run preremove scripts 2. Actually remove files. This is still not perfect, but should resolve the majority of issues, and not just relating to the cygwin package itself. Okeydoke, I'll look at it. I took the approach I did because it seemed like the least-invasive approach and thought it would catch at least some of the worst cases. I don't _suppose_ leaving the uninstall files present while running subsequent preremove scripts should affect anything, but it's certainly a larger operational change. Anyway, I'll drop a line back when I've got a new patch to try. Since we have never made any ordering guarantees regarding preremove scripts, I think its fine. The other potential solution would be to attempt to uninstall the packages in dependency-sorted order, but that might get awkward in the case of circular dependencies. Max.
Re: Welcoming Brian Dessent as setup maintainer
Christopher Faylor wrote: I've asked Brian Dessent if he would like to become an official maintainer of setup.exe and he has graciously accepted. On that note, I would like to start an open dialog about bugfixes and features for setup. As all of you know, things seem to move glacially slow with development of setup. Perhaps that's good in that we don't surprise our users :) however it does mean that there is a lot that could be improved. The main thing I have been working on lately is a change that will double check the user's choices after they are done selecting packages. If there are no unmet requirements, setup just moves on to the next stage as normal with no change in UI. If it finds anything missing, it adds another page to the wizard that lists the missing packages and which packages depend on them. There is a checkbox at the bottom labeled Install these packages to meet dependences, and if the user just presses Next all the required packages are added. The user can also press Prev and modify the selection, or if he's brave he can uncheck the box and continue anyway. If he does that he gets a stern popup that asks if he's sure he wants to continue, given that breakage will likely occur. Below is an example of what it looks like. I set everything in category Base to Uninstall and then pressed Next (!). http://dessent.net/tmp/setup-depends1.png If the user unchecks the checkmark at the bottom and attempts to continue, he is met with this: http://dessent.net/tmp/setup-depends2.png I still need to do some polishing and I would certainly want to solicit feedback from all of you and do testing before letting it anywhere near users. My hope with this addition is to catch any dependency errors that cause broken installs and user frustration -- be it through setup bugs or user error. Here are some other things that I would like to address. Please let me know if you think they are good or bad ideas. Bug Fixes / New Features (in no particular order) - I still have not had a chance to review Dave Korn's postinstall/preremove script. I do know that there's no truly foolproof way of handling this issue though. Some postinstalls might depend on packages that you're trying to upgrade, and would bomb if you removed those files first. There was a long mailing list thread on this a while ago that basically came to the conclusion that there was no easy answer. - A user reported a unique issue earlier today that deals with trying to upgrade older packages. If you have a package that is old enough that it has fallen off the mirrors, and you don't have a copy in your local cache, then setup treats it slightly differently since it doesn't have a source for it. This can result in not being able to even get the current version selected. I can reproduce this easily and I know the part of the code that needs help (packagemeta::set_action()), so I hope to arrive at something that works a little better in this situation. - setup is already fairly cryptic, it does not help that there are absolutely no help buttons. We have to keep it as a single monolithic executable (so no external help files), but I believe that we can still add context-sensitive help that would display a popup balloon after you click on the ? and then click on the thing you want help with. - setup should be able to save and restore its window position and size. This is a personal peeve of mine. I know the whole resizeability thing was a huge complicated issue back in the day. I have no desire to change how it acts out of the box, but I just think that it should remember whatever size you make it. This also applies to all those annoying things like desktop shortcuts and so on. Basically it shouldn't pester you for the same stuff over and over; what you set, it should remember. - The user mode/system mode mount thing seems to be wearing out its welcome. Seems like for a lot of people, system mounts are the way to go and there's no reason complicating it for them. But there will still be cases -- be it lacking admin permissions, or desire to support multiple users -- where you still want user mounts. So we can't just rip it all out, but it does seem reasonable that we could first check for admin privileges, and if they exist then assume system-wide mounts for new installs. Existing installs would keep whatever they're set to, and we'd need some way for people that want to use user mode mounts to easily do that - maybe a command line switch, or a setting in a file. - If the user has entered by hand a mirror location or is using an ancient mirror, it could really detract from their experience if they're getting stale packages. Setup should probably warn or gently prod the user if it detects that the mirror they're using isn't on the cygwin.com list. (cgf pointed me towards this issue.) Again, I'm sure there are lots of people out there that are legitimately using mirror locations not on the
Re: Welcoming Brian Dessent as setup maintainer
On May 3 13:58, Brian Dessent wrote: - I still have not had a chance to review Dave Korn's postinstall/preremove script. I do know that there's no truly foolproof way of handling this issue though. Some postinstalls might depend on packages that you're trying to upgrade, and would bomb if you removed those files first. There was a long mailing list thread on this a while ago that basically came to the conclusion that there was no easy answer. Was there any other problem besides circular dependencies? Circular dependencies are bugs in the setup.hint files, IMHO. It would be nice(tm) if setup would recognize them. but actually they should somehow be avoided at all. The Cygwin installation dependency should be a tree with the root being the cygwin package, shouldn't it? * ** The current user experience of setup.exe is needlessly harsh, ** ** and I think we can improve that without _too_ much effort. It's ** ** just that we're so used to it that we all know how it works and ** ** its idiosyncracies. ** * While we're at it: I'm using an ftp mirror which has a pretty short timeout period. It's so short, that sometimes if I select packages from scratch for a new installation, the server timed out before I finished package selection. When pressing the next button, setup chokes. I think setup should reconnect instead. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: Welcoming Brian Dessent as setup maintainer
Brian, My major pet peeve has always been that setup.exe doesn't do any sanity checks on mount points to ensure that they actually exist on disk before starting the install process. Of course, if a mount point points to the D: drive that has been removed, setup effectively untars the packages to /dev/null, which doesn't help much :) I propose this solution: 1) Check each mount point to see if it actually points somewhere valid. 2) If any mount points point to invalid locations. a) Present a dialog, listing the invalid mount points b) Ask the user if they wish to continue the installation anyway I think that 2b) is required because I may have a mount point for /foo that points to z: which isn't there because I'm not on the network, but that souldn't stop the installation from happening since /usr /bin /etc, et al are all valid. Of course, there is an alternative: 1) Check each mount point 2) Remove any mount point that points to an unavailable location 3) Bail if / is then undefined This would have the effect of removing an invalid /usr/bin mount point, allowing the installation to continue to the default / mount point, and ... pretty confusing, eh? Forget it, go with the first option. Harold
Re: [PATCH] Uninstall .dll last, reinstall first - final version
On May 3 21:49, Max Bowsher wrote: The other potential solution would be to attempt to uninstall the packages in dependency-sorted order, but that might get awkward in the case of circular dependencies. See my previous posting: Circular dependencies are bugs, right? Creating a dependency tree and complaining about circular dependencies in setup would be nice, though. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
RE: Welcoming Brian Dessent as setup maintainer
[snip] Bug Fixes / New Features (in no particular order) [snip] - setup is already fairly cryptic, it does not help that there are absolutely no help buttons. We have to keep it as a single monolithic executable (so no external help files), I'm not sure that is a precondition. Cygwin setup could very easily be packaged up with InnoSetup into a single downloadable exe, but it would be a regular Windows installer, and setup.exe and any number of support files it might require could be installed just like any other application. In fact, it seems to me that even it did stay a single exe, having a regular installation process like this would be good, if only to eliminate the question of where do I put setup.exe? Adding HTML help, when it's a separate file anyway, is dead simple. [snip] - The user mode/system mode mount thing seems to be wearing out its welcome. Seems like for a lot of people, system mounts are the way to go and there's no reason complicating it for them. But there will still be cases -- be it lacking admin permissions, or desire to support multiple users -- where you still want user mounts. So we can't just rip it all out, but it does seem reasonable that we could first check for admin privileges, and if they exist then assume system-wide mounts for new installs. Existing installs would keep whatever they're set to, and we'd need some way for people that want to use user mode mounts to easily do that - maybe a command line switch, or a setting in a file. Many of the new programs I've installed recently ask the very similar question of Do you want to install for all users of this computer, or just the current user?, albeit usually for different reasons, so I don't see anything fundamentally wrong with the status quo. I think simply clarifying this functionality (along with the DOS/UNIX mounts etc) and/or not asking it every time (as I believe others may have already suggested) would essentially solve any current issues there (UI issues anyway). - If the user has entered by hand a mirror location or is using an ancient mirror, it could really detract from their experience if they're getting stale packages. Setup should probably warn or gently prod the user if it detects that the mirror they're using isn't on the cygwin.com list. (cgf pointed me towards this issue.) Again, I'm sure there are lots of people out there that are legitimately using mirror locations not on the official list, so I'm thinking of something along the lines of a warning message with an option to don't ask me again, or at least don't ask me again unless I enter a new url that's also not on the list. I still maintain that the whole Select a mirror thing is not something that should normally be user-visible. By far the most common use case is the user trying to update their current Cygwin installation with updated and/or new programs, and they absolutely don't care which mirror they're coming from. They certainly shouldn't be expected to know which ones are current, nor which ones are better than the others, nor which are currently available, because they simply won't know. Some automatic means of deciding this stuff should exist, and be the default way mirror selection works. Install from a specific mirror or whatever can require the user to press another button or two, or set an Options checkbox somewhere, as it should. [snip] - Very minor cosmetic thing, but we should include a manifest with the .exe. With that one change you get the updated common controls that were added in XP. You can see this in the screen shots above actually, I've been building it that way for a while now. Now, I'm fully prepared for the jokes about XP looking like fischer price (My first OS!) but it doesn't hurt to spruce up the appearance a little bit since that kind of thing matters to a lot of people. It's essentially a free change, you just add the manifest and that's it, you don't have to maintain anything. I would of course want to test it on all the older 9x systems but I'm fairly sure they degrade fine (the manifest I used was more or less the boilerplate one from the SDK.) I was never able to get this to fully work, as the resource compiler wasn't able to handle manifest resources. Are you sure that this is really working for you? I was fooled for a while, because if you have the manifest file in the same directory Windows will use that and it will work fine, but move the exe and it suddenly is back to the non-themed olde-tyme controls. (Maybe another reason to go to an InnoSetup installer?) I think I recall doing some not-insignificant work on the SDK boilerplate, for reasons that are lost to the fog of time. I can dig that up if you think you might be able to make use of it. [snip] One thing you didn't explicitly state, but is implied by many of your points, is that the UI and business
Re: Welcoming Brian Dessent as setup maintainer
Corinna Vinschen wrote: While we're at it: I'm using an ftp mirror which has a pretty short timeout period. It's so short, that sometimes if I select packages from scratch for a new installation, the server timed out before I finished package selection. When pressing the next button, setup chokes. I think setup should reconnect instead. Heh, that is pretty unfriendly, I was not aware of that one... Brian
Re: Welcoming Brian Dessent as setup maintainer
Gary R. Van Sickle wrote: I'm not sure that is a precondition. Cygwin setup could very easily be packaged up with InnoSetup into a single downloadable exe, but it would be a regular Windows installer, and setup.exe and any number of support files it might require could be installed just like any other application. In fact, it seems to me that even it did stay a single exe, having a regular installation process like this would be good, if only to eliminate the question of where do I put setup.exe? Adding HTML help, when it's a separate file anyway, is dead simple. Another possibility might be to embed the .chm or .hlp file in the .exe as a resource. I don't know if that's feasible or not. Still, the context sensitive help would go a long way, and there is a manual in html that they can refer to online. Many of the new programs I've installed recently ask the very similar question of Do you want to install for all users of this computer, or just the current user?, albeit usually for different reasons, so I don't see anything fundamentally wrong with the status quo. I think simply clarifying this functionality (along with the DOS/UNIX mounts etc) and/or not asking it every time (as I believe others may have already suggested) would essentially solve any current issues there (UI issues anyway). The problem is joe user installs for me and then tries to install a service like sshd, cron, etc. And it naturally fails because SYSTEM doesn't see any mounts. So one or more of (setup.exe, cygrunsrv, /usr/bin/foo-install-script) probably needs to do more sanity checking in those cases. I still maintain that the whole Select a mirror thing is not something that should normally be user-visible. By far the most common use case is the user trying to update their current Cygwin installation with updated and/or new programs, and they absolutely don't care which mirror they're coming from. They certainly shouldn't be expected to know which ones are current, nor which ones are better than the others, nor which are currently available, because they simply won't know. Some automatic means of deciding this stuff should exist, and be the default way mirror selection works. Install from a specific mirror or whatever can require the user to press another button or two, or set an Options checkbox somewhere, as it should. Ahh but that's been in place for something like 3 years already. The script is here: http://sources.redhat.com/cgi-bin/cvsweb.cgi/htdocs/check-mirrors?rev=1.49content-type=text/x-cvsweb-markupcvsroot=cygwin The mirrors.lst and the list on the website are generated by a perl script that polls them all regularly and drops any that don't respond or have a setup.ini that's more than a few days stale. Any mirror on the list is guaranteed to be good. The reason why users *do* need to know which mirror they are using is that currently the local cache is keyed to the url. (As I am sure you very well know.) So if you frequently hop around mirrors, you get duplication in the cache. I would imagine that most users want the control of it to the extent that they can find a site they like a stick with it -- I know that's what I do, and I'd be very hostile if suddenly setup.exe did the picking for me. I was never able to get this to fully work, as the resource compiler wasn't able to handle manifest resources. Are you sure that this is really working for you? I was fooled for a while, because if you have the manifest file in the same directory Windows will use that and it will work fine, but move the exe and it suddenly is back to the non-themed olde-tyme controls. (Maybe another reason to go to an InnoSetup installer?) Yes, it's in a different directory. Just to veryify I tried renaming the manifest and it works fine. I think windres has progressed since you last tried. I was actually going to post those patches just now, and a compiled .exe, so that people can test that. I think I recall doing some not-insignificant work on the SDK boilerplate, for reasons that are lost to the fog of time. I can dig that up if you think you might be able to make use of it. The only thing that gave me pause was the version attribute of the assemblyIdentity tag, which is supposed to be in n.n.n.n format. I just set it to 1.0.0.0 and see no reason why it would need to be dynamically updated. It's not like the file version resource, and as far as I know nothing really reads that. One thing you didn't explicitly state, but is implied by many of your points, is that the UI and business logic badly need to be disentangled. Max, myself, and others have picked away at that over the years, but last I checked there still was not a clear division. I think it would be fabulous if setup.exe was just a gui that manipulated a list of which packages you wanted, and there was some other back-end that did the downloading, installing, and removing. (Kind of like the divide between
[patch] manifest, and test release
So, I see that you have taken care of the markVisited() bug. There's that one, the proxy port one, and the d.sh postinstall one, all of which still exist in the wild in current setup.exe no? I'm posting the patch for the manifest. If there are no objections I'd like to commit this and see about rolling a test release soon. How does that sound Max? 2005-05-03 Brian Dessent [EMAIL PROTECTED] * res.rc: (CREATEPROCESS_MANIFEST_RESOURCE_ID): Define so that manifest is included in the binary. This causes the common controls to appear more modern on recent versions of Windows. * setup.exe.manifest: New file.Index: res.rc === RCS file: /cvs/cygwin-apps/setup/res.rc,v retrieving revision 2.58 diff -u -r2.58 res.rc --- res.rc 20 Nov 2004 17:25:29 - 2.58 +++ res.rc 3 May 2005 22:51:40 - @@ -497,6 +497,8 @@ IDS_UNCAUGHT_EXCEPTION_WITH_ERRNO Fatal Error: Uncaught Exception\nThread: %s\nType: %s\nMessage: %s\nAppErrNo: %d END +CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST setup.exe.manifest + #endif// English (U.S.) resources / --- /dev/null 2005-05-03 15:56:41.072375000 -0700 +++ setup.exe.manifest 2005-05-03 15:23:04.61925 -0700 @@ -0,0 +1,22 @@ +?xml version=1.0 encoding=UTF-8 standalone=yes? +assembly xmlns=urn:schemas-microsoft-com:asm.v1 manifestVersion=1.0 +assemblyIdentity +version=1.0.0.0 +processorArchitecture=X86 +name=RedHat.Cygwin.Setup +type=win32 +/ +descriptionCygwin installation tool/description +dependency +dependentAssembly +assemblyIdentity +type=win32 +name=Microsoft.Windows.Common-Controls +version=6.0.0.0 +processorArchitecture=X86 +publicKeyToken=6595b64144ccf1df +language=* +/ +/dependentAssembly +/dependency +/assembly
Re: [PATCH] Uninstall .dll last, reinstall first - final version
Hi All... Should the actual file deletion be moved to a later phase? What I mean is where deletions are now performed, should files to be deleted be appended to a list (of files to be deleted), and then deleted all at once? Thanks, ...Karl From: Max Bowsher To: Dave Korn Subject: Re: [PATCH] Uninstall .dll last, reinstall first - final version Date: Tue, 3 May 2005 19:54:55 +0100 Dave Korn wrote: Well, it builds, and it works, and I've tested it by rolling an installation back-and-forth across quite a large update (the difference between my local mirror set up last september and an up-to-date mirror), which I could do with the old setup and see things fail when it removed the cygwin dll early in the uninstall, and which worked fine with the patched version because it saves the dll until last, and nobody actually has any comments, but I've cut out the unnecessary return-an-early-abort-indication bit now that I'm convinced that LogSingleton::exit doesn't return. So I'd call that done for now. Here ya go! The problem with this is it special cases the cygwin package. Whilst undoubtably this is the one thing that almost everything depends on, there are other dependency issues which this does not touch. It is definitely valuable to have the section of code causing the problem pinpointed, but I think what we should do instead is to break out the uninstallation phase into two seperate passes: 1. Run preremove scripts 2. Actually remove files. This is still not perfect, but should resolve the majority of issues, and not just relating to the cygwin package itself. Max.
Re: Welcoming Brian Dessent as setup maintainer
Brian Dessent wrote: that currently the local cache is keyed to the url. Another thing to discuss is whether that, itself, is a bug. Max.
Re: [patch] manifest, and test release
Brian Dessent wrote: So, I see that you have taken care of the markVisited() bug. Almost. One more commit coming up to finish that one off. Everything I've committed so far has been things that I encountered whilst reviewing, rather than your change itself. There's that one, the proxy port one, and the d.sh postinstall one, all of which still exist in the wild in current setup.exe no? Yes, that is correct. I'm posting the patch for the manifest. If there are no objections I'd like to commit this and see about rolling a test release soon. How does that sound Max? There is one remaining issue - here is a ChangeLog entry from the current release branch: 2004-11-28 Max Bowsher [EMAIL PROTECTED] * download.cc (check_for_cached): Re-introduce the silent skipping of wrong-sized package files in local caches, as a quick fix that is no worse than the status quo, to be able to make a release, whilst work towards a proper fix continues on trunk. It's getting late here - let me reexamine it in the morning, and I'll summarize the situation in a bit more detail. 2005-05-03 Brian Dessent [EMAIL PROTECTED] * res.rc: (CREATEPROCESS_MANIFEST_RESOURCE_ID): Define so that manifest is included in the binary. This causes the common controls to appear more modern on recent versions of Windows. * setup.exe.manifest: New file. Good! With one minor comment below... Index: res.rc === RCS file: /cvs/cygwin-apps/setup/res.rc,v retrieving revision 2.58 diff -u -r2.58 res.rc --- res.rc 20 Nov 2004 17:25:29 - 2.58 +++ res.rc 3 May 2005 22:51:40 - @@ -497,6 +497,8 @@ IDS_UNCAUGHT_EXCEPTION_WITH_ERRNO Fatal Error: Uncaught Exception\nThread: %s\nType: %s\nMessage: %s\nAppErrNo: %d END +CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST setup.exe.manifest + #endif// English (U.S.) resources / --- /dev/null 2005-05-03 15:56:41.072375000 -0700 +++ setup.exe.manifest 2005-05-03 15:23:04.61925 -0700 @@ -0,0 +1,22 @@ +?xml version=1.0 encoding=UTF-8 standalone=yes? +assembly xmlns=urn:schemas-microsoft-com:asm.v1 manifestVersion=1.0 +assemblyIdentity +version=1.0.0.0 +processorArchitecture=X86 +name=RedHat.Cygwin.Setup ... perhaps just Cygwin.Setup here ? Max.
Re: [patch] manifest, and test release
Max Bowsher wrote: Brian Dessent wrote: So, I see that you have taken care of the markVisited() bug. Almost. One more commit coming up to finish that one off. Everything I've committed so far has been things that I encountered whilst reviewing, rather than your change itself. Done now. There's that one, the proxy port one, and the d.sh postinstall one, all of which still exist in the wild in current setup.exe no? Yes, that is correct. Actually, to correct myself, the d.sh one isn't in the wild. It was only broken on trunk for a while. Max.
Re: Welcoming Brian Dessent as setup maintainer
Brian Dessent wrote: Another possibility might be to embed the .chm or .hlp file in the .exe as a resource. I don't know if that's feasible or not. Tricky at best. Both WinHelp.exe and hh.exe are separate programs, and their APIs seem to have no way to tell them to look at a resource inside another EXE. I seem some mumblings in the HTMLHelp docs about using an ActiveX control with IE, so perhaps you could embed IE in order to display your HH file, butick. Still, the context sensitive help would go a long way, and there is a manual in html that they can refer to online. Context-sensitive help is just resources, so that wouldn't require a traditional Windows installer. I recall that it's tricky to do outside a dialog, though. Perhaps setup.exe could have a button to launch the default browser to open the online Cygwin docs from setup.exe. I believe the Shell API has a way to do this, where you just open a URL. ShellExecute(), perhaps?
RE: Welcoming Brian Dessent as setup maintainer
Original Message From: Warren Young Sent: 04 May 2005 00:42 Brian Dessent wrote: Another possibility might be to embed the .chm or .hlp file in the .exe as a resource. I don't know if that's feasible or not. Tricky at best. Both WinHelp.exe and hh.exe are separate programs, and their APIs seem to have no way to tell them to look at a resource inside another EXE. I seem some mumblings in the HTMLHelp docs about using an ActiveX control with IE, so perhaps you could embed IE in order to display your HH file, butick. The traditional hack for situations like this (it also crops up if you want to bundle a .dll as a binary resource in your .exe and LoadLibrary it at runtime, blech!) is to include the file as a binary resource, then at runtime write the data of that resource to a temporary file and use that file instead, deleting the file on exit! cheers, DaveK -- Can't think of a witty .sigline today
Re: [patch] manifest, and test release
Max Bowsher wrote: There is one remaining issue - here is a ChangeLog entry from the current release branch: 2004-11-28 Max Bowsher [EMAIL PROTECTED] * download.cc (check_for_cached): Re-introduce the silent skipping of wrong-sized package files in local caches, as a quick fix that is no worse than the status quo, to be able to make a release, whilst work towards a proper fix continues on trunk. Yuck... that sounds like one of those corner cases that's never fun to deal with - do you try to resume the transfer, and hope the md5sum is correct, or do you just delete ir or rename it out of the way. I will try to look more into the oddity reported earlier today... +name=RedHat.Cygwin.Setup ... perhaps just Cygwin.Setup here ? Max. To be honest I have no idea, but was going by what the SDK says. About 'name' it says: Uniquely names the application or assembly. Use the following format for the name: Organization.Division.Name. For example Microsoft.Windows.mysampleApp. Required. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/manifest_files_reference.asp Actually, reading through those docs again I'm slightly worried about the version thing again: Every side-by-side assembly must have a version. Each assembly version is associated with a version number having four parts separated by periods: major.minor.build.revision. If a change is made to an assembly making it incompatible with existing versions, the major or minor parts of the version number must be changed. A version number that changes only in the build or revision parts indicates that the assembly is backward compatible with prior versions. We could, without too much hassle, run sed on the thing at build time to subsitute the ChangeLog version in there, adding 0s as necessary for missing fields. However, I have to wonder what they really mean when they say, change is made to an assembly making in incompatible. As far as I know, that seems to apply more to their .NET stuff, where these manifests actually contain useful information. From what I can tell, the only thing this is doing in our case is saying, Yes, I'd like the comctl32 version 6 please, thank you and that's it. So I guess it's fine to leave the version at 1.0.0.0 indefinitely. Brian
Re: Welcoming Brian Dessent as setup maintainer
On Wed, May 04, 2005 at 12:15:37AM +0100, Max Bowsher wrote: Brian Dessent wrote: that currently the local cache is keyed to the url. Another thing to discuss is whether that, itself, is a bug. It's not a bug, per se, since it was designed that way, wasn't it? cgf
Re: [PATCH] Uninstall .dll last, reinstall first - final version
On Tue, May 03, 2005 at 04:16:54PM -0700, Karl M wrote: Hi All... Should the actual file deletion be moved to a later phase? What I mean is where deletions are now performed, should files to be deleted be appended to a list (of files to be deleted), and then deleted all at once? It seems like files should only be deleted after all of the postinstall scripts have run. cgf
Re: Welcoming Brian Dessent as setup maintainer
On Tue, 2005-05-03 at 21:00 -0400, Christopher Faylor wrote: On Wed, May 04, 2005 at 12:15:37AM +0100, Max Bowsher wrote: Brian Dessent wrote: that currently the local cache is keyed to the url. Another thing to discuss is whether that, itself, is a bug. It's not a bug, per se, since it was designed that way, wasn't it? So theres one key reason for the keying to URL: cache pollution. 3rd party sites with the same file name, different md5 - but matching their .ini file - should not be able to prevent you getting the package you wanted. Or worse getting their (as it passes their md5 entry) package without warning. Cheers, Rob signature.asc Description: This is a digitally signed message part
Re: [PATCH] Uninstall .dll last, reinstall first - final version
On Tue, 3 May 2005, Corinna Vinschen wrote: On May 3 21:49, Max Bowsher wrote: The other potential solution would be to attempt to uninstall the packages in dependency-sorted order, but that might get awkward in the case of circular dependencies. See my previous posting: Circular dependencies are bugs, right? Creating a dependency tree and complaining about circular dependencies in setup would be nice, though. Circular dependencies are not bugs. Circular dependencies just mean that the packages are interdependent -- each requires the other's functionality. Besides, installation dependencies aren't quire the same as uninstallation dependencies. I've posted on this topic before -- I'll try to dig up the exact URL later. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: [PATCH] Uninstall .dll last, reinstall first - final version
On Tue, 3 May 2005, Christopher Faylor wrote: On Tue, May 03, 2005 at 04:16:54PM -0700, Karl M wrote: Hi All... Should the actual file deletion be moved to a later phase? What I mean is where deletions are now performed, should files to be deleted be appended to a list (of files to be deleted), and then deleted all at once? It seems like files should only be deleted after all of the postinstall scripts have run. You must mean preremove here. This won't help if the preremove scripts delete files that are needed for the package executables to function. It'll work for most packages, though. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: Welcoming Brian Dessent as setup maintainer
Brian Dessent wrote: That reminds me... another idea that cgf mentioned earlier was having setup.exe offer to show the README files of packages it just installed. I'd only go for that if there were a short version of the README, containing just the barest things you need to be aware of when installing the package. For instance, the ssh README would be something like: OpenSSH will only work as a client by default. To set it up as a server, see /usr/share/doc/Cygwin/openssh.README. I say this because the openssh README is 233 lines long. I just don't see someone taking the time during install to read too many such files. Rather than try to shorten these READMEs (inappropriate, IMHO), there needs to be a separate facility to tell users what the major limitations of a port are, where to look next for info on getting around those limits, and how to configure the package if it requires that. Some mechanism ideas: it could be a single dialog, wizard-like, with a big text area to show the setup hint text, with a big bold title above that with the human name of the package. (OpenSSH vs. openssh) Perhaps that dialog could have a button that would directly open the full README, for when the reader's interest is immediately piqued on a topic. Open the file in Notepad, so it stays open after setup.exe goes away. It wouldn't actually have to be a separate file within the package. It could be part of the package's .hint file. To be effective, the option would have to be enabled by default, with the ability to turn it off. And that brings us back to setup.exe being able to remember your choices from one run to the next.
Re: Welcoming Brian Dessent as setup maintainer
On Tue, 3 May 2005, Brian Dessent wrote: Christopher Faylor wrote: I've asked Brian Dessent if he would like to become an official maintainer of setup.exe and he has graciously accepted. On that note, I would like to start an open dialog about bugfixes and features for setup. As all of you know, things seem to move glacially slow with development of setup. Perhaps that's good in that we don't surprise our users :) however it does mean that there is a lot that could be improved. [snip] Here are some other things that I would like to address. Please let me know if you think they are good or bad ideas. One other thing that might help modem users is having setup display the size of the package they're about to download (that way, they won't be surprised when downloading an update of xorg-x11-f100 takes hours). I have had a preliminary patch on this for a long while, but no chance to work further on it. There are some bugs, but the basic functionality is there. Brian, would you be interested in reviewing it? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: [PATCH] Uninstall .dll last, reinstall first - final version
Igor Pechtchanski wrote: Circular dependencies are not bugs. Well, there are two types of circular dependencies, and they're only a problem in one of these instances. Circular dependencies of packages in operation is not a problem. That is, you can say that there is Package A which uses facilities in Package B, and vice versa, and this is not a problem. These two packages simply have be installed together or uninstalled together to avoid a dependency problem. Circular dependencies during the [un]installation process _is_ a problem. This is where we get the old problem of cygwin.dll or bash being removed during an upgrade before all the uninstall scripts for other packages are run. This requires a different dependency tree than required to solve the above problem. The distinction is this: it can't be said that 'man' requires /bin/sh in operation, but its uninstall script does. We shouldn't demand that bash be installed along with man, because any of several packages can provide /bin/sh. But if bash is the one providing /bin/sh on your system, it has to be removed after man during an upgrade where both packages have been updated.
Re: Welcoming Brian Dessent as setup maintainer
Warren Young wrote: To be effective, the option would have to be enabled by default, with the ability to turn it off. I've thought of a better way to handle this: versioned setup hints. The first time you install Cygwin, you have to at least skip past all of the hints explicitly. When you upgrade a package, the hint probably won't have changed, so setup.exe won't show it to you again. But if there is a change, setup.exe does show the hint again. A package maintainer would only change the hint when some critical thing happens. To reuse the OpenSSH example, any package change that requires you to re-run ssh-host-config would require a change to the setup hint.
Re: Welcoming Brian Dessent as setup maintainer
Igor Pechtchanski wrote: I have had a preliminary patch on this for a long while, but no chance to work further on it. There are some bugs, but the basic functionality is there. Brian, would you be interested in reviewing it? Yes, certainly. It would be nice to try to use these things that exist already (like ldesc or package size) for some useful purpose. Disk usage would be a good candidate since it could be a running sum and a lot easier to work into the screen real estate. Brian
Re: [PATCH] Uninstall .dll last, reinstall first - final version
On Tue, May 03, 2005 at 10:08:32PM -0400, Igor Pechtchanski wrote: On Tue, 3 May 2005, Christopher Faylor wrote: On Tue, May 03, 2005 at 04:16:54PM -0700, Karl M wrote: Hi All... Should the actual file deletion be moved to a later phase? What I mean is where deletions are now performed, should files to be deleted be appended to a list (of files to be deleted), and then deleted all at once? It seems like files should only be deleted after all of the postinstall scripts have run. You must mean preremove here. This won't help if the preremove scripts delete files that are needed for the package executables to function. It'll work for most packages, though. Yes. I meant preremove. cgf
Re: Welcoming Brian Dessent as setup maintainer
On Tue, May 03, 2005 at 08:16:58PM -0600, Warren Young wrote: Brian Dessent wrote: That reminds me... another idea that cgf mentioned earlier was having setup.exe offer to show the README files of packages it just installed. I'd only go for that if there were a short version of the README, containing just the barest things you need to be aware of when installing the package. For instance, the ssh README would be something like: OpenSSH will only work as a client by default. To set it up as a server, see /usr/share/doc/Cygwin/openssh.README. No, that would, IMO, be of little benefit. People should be presented with the option of reading the README. If they don't want to, then they don't have to, but at least they will know that there is a README, and may even be able to figure out where it is. Introducing another short README is just a needless headache for a package maintainer. To be effective, the option would have to be enabled by default, with the ability to turn it off. And that brings us back to setup.exe being able to remember your choices from one run to the next. I don't think that the option of reading READMEs should ever be turned off, unless it's via a command line option. I'd rather annoy people with the prospect of documentation than casually turn it off because they decided once that they didn't want to see it. cgf
Re: [PATCH] Uninstall .dll last, reinstall first - final version
On Tue, 3 May 2005, Warren Young wrote: Igor Pechtchanski wrote: Circular dependencies are not bugs. Well, there are two types of circular dependencies, and they're only a problem in one of these instances. Circular dependencies of packages in operation is not a problem. That is, you can say that there is Package A which uses facilities in Package B, and vice versa, and this is not a problem. These two packages simply have be installed together or uninstalled together to avoid a dependency problem. Circular dependencies during the [un]installation process _is_ a problem. This is where we get the old problem of cygwin.dll or bash being removed during an upgrade before all the uninstall scripts for other packages are run. This requires a different dependency tree than required to solve the above problem. The distinction is this: it can't be said that 'man' requires /bin/sh in operation, but its uninstall script does. We shouldn't demand that bash be installed along with man, because any of several packages can provide /bin/sh. But if bash is the one providing /bin/sh on your system, it has to be removed after man during an upgrade where both packages have been updated. I also wrote, in that same message: Besides, installation dependencies aren't quire the same as uninstallation dependencies. I've posted on this topic before... I understand the need to save bandwidth, but snipping away the relevant part of the message, and then repeating it in the reply (albeit in some more detail) isn't a particularly helpful use of the bandwidth either. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: Welcoming Brian Dessent as setup maintainer
Larry Hall wrote: I guess I'm wondering why we would want the user to be able to continue the installation if the dependencies weren't satisfied (i.e. what value the checkbox for the dependencies has). It seems to me that it guarantees a broken installation. No matter how clearly we state to the user that this will be the result, I can't imagine anyone taking this route and being pleased with the result. So that just leaves us with the folks that didn't understand or didn't pay attention and went ahead anyway. Granted, that's recoverable but it means we'll get questions on the list about it. If I'm right about that, then it seems to me that this would be a good argument from only allowing them to continue with the dependencies found or to go back and change their original selections. You may be onto something there. The whole point of this exercise was to reduce broken Cygwin installations, and reduce unhappy users. If having a broken installation is still possible by misunderstanding a dialog but continuing anyway, then it doesn't really net anything. I can think of some situations where you might find it handy to override setup's wishes, but I have to admit most of them are pretty far fetched. The only one that makes any sense is when you're trying to uninstall a large dependency tree, such as if you want to get rid of X11. The last time I tried this it was quite hard, since you would turn off one package, but in the process of cycling the next you would wind up re-enabling the one you just turned off. I think it's possible to do it but you have to do something really stupid like put half the packages in 'Source', then disable the other half, then finally you can cycle the first set to Uninstall since there's no version number in between Source and Uninstall. Makes me kind of sick just thinking about expecting someone not familiar with setup to figure that out. I guess that gets into a whole other area though, that you should either be able to mass-deselect a number of packages at once, or have some way of deselecting a package without cycling through other versions of it. :/ But back to Larry's point. Should we refuse to even give them the rope lest they hang themselves? Brian
Re: Welcoming Brian Dessent as setup maintainer
On Tue, May 03, 2005 at 08:12:20PM -0700, Brian Dessent wrote: But back to Larry's point. Should we refuse to even give them the rope lest they hang themselves? I'm all for that idea. Maybe we need a setup --nodeps or a setup --expert option. cgf
Summary, was Re: Welcoming ...
Brian Dessent wrote: On that note, I would like to start an open dialog about bugfixes and Here's the synopsis of this thread and other recent conversations: - explicit depends checking (perhaps enforced) - what to do about cached packages of wrong size - ordering of the unpack/replace (davek) (potentially grooming setup.hints to remove cycles) - older package no longer on mirror or cache = odd version cycling - context sensitive help or embedded .chm/.hlp (or maybe just a button that launches url shortcut to online manual) - save window position and misc settings (possibly default to a percentage of screen rather than tiny size) - deprecate needless user-mode mounts - have intelligence when unpacking that path is valid (and/or check mounts for garbage, but careful of network drives) - warn if user's mirror is not on current list - function without needing cygwin.com phonehome; potentially cache mirrors.lst - manifest for themed controls - accessibility or just less confusing package selection widget (or maybe just a way to uninstall things like X11 easily) - show disk space usage during selection (and anything else useful like ldesc) - ftp connections shouldn't be kept open during package selection - offer user chance to view READMEs after installation (or provide pointer to their location) - setup is totally unresponsive to input during long md5 checks of local package repo Well, it sure ain't pretty and I can tell for you a fact that they're not all getting fixed in this lifetime. But it's good to have a list at least. If there was anything I missed, please add. Brian
Re: Welcoming Brian Dessent as setup maintainer
On Tue, 3 May 2005, Brian Dessent wrote: Larry Hall wrote: I guess I'm wondering why we would want the user to be able to continue the installation if the dependencies weren't satisfied (i.e. what value the checkbox for the dependencies has). It seems to me that it guarantees a broken installation. No matter how clearly we state to the user that this will be the result, I can't imagine anyone taking this route and being pleased with the result. So that just leaves us with the folks that didn't understand or didn't pay attention and went ahead anyway. Granted, that's recoverable but it means we'll get questions on the list about it. If I'm right about that, then it seems to me that this would be a good argument from only allowing them to continue with the dependencies found or to go back and change their original selections. You may be onto something there. The whole point of this exercise was to reduce broken Cygwin installations, and reduce unhappy users. If having a broken installation is still possible by misunderstanding a dialog but continuing anyway, then it doesn't really net anything. I can think of some situations where you might find it handy to override setup's wishes, but I have to admit most of them are pretty far fetched. The only one that makes any sense is when you're trying to uninstall a large dependency tree, such as if you want to get rid of X11. The last time I tried this it was quite hard, since you would turn off one package, but in the process of cycling the next you would wind up re-enabling the one you just turned off. I think it's possible to do it but you have to do something really stupid like put half the packages in 'Source', then disable the other half, then finally you can cycle the first set to Uninstall since there's no version number in between Source and Uninstall. Makes me kind of sick just thinking about expecting someone not familiar with setup to figure that out. I guess that gets into a whole other area though, that you should either be able to mass-deselect a number of packages at once, or have some way of deselecting a package without cycling through other versions of it. :/ But back to Larry's point. Should we refuse to even give them the rope lest they hang themselves? I, for one, regularly break setup's dependencies on my install (for example, so that the X server isn't dragged in with the rest of the X packages -- I use Exceed). But that certainly requires someone who knows what they're doing. The problem, as I see it, is that there are two kinds of dependencies semantically -- suggested and required -- but setup supports only one kind, so they both get merged. There is no way for setup to distinguish between things that are there because they really are needed, and things that are there because the maintainers want some obscure parts of their packages (e.g., X GUIs) to work OOTB. If we made such a distinction, I would be all for disallowing the user to deselect required dependencies and using Brian's proposal for suggested ones. As things stand now, though, I'd prefer to have the flexibility. FWIW, I like the --expert option suggested by CGF. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT
Re: [patch] fix for the proxy port preference not being saved
Brian Dessent schrieb: This is the much-requested fix for the problem of not saving the proxy port. I had always expected this was some kind of trivial bug that just needed a quick fix, but I was incorrect. It was much more subtle than I gave it credit for.
Re: Welcoming Brian Dessent as setup maintainer
Christopher Faylor wrote: I don't think that the option of reading READMEs should ever be turned off, unless it's via a command line option. I'd rather annoy people with the prospect of documentation than casually turn it off because they decided once that they didn't want to see it. At the very least, consider my versioning idea. I shouldn't have to page through the same set of READMEs every time I upgrade Cygwin.
