RE: [PATCH] Setup Chooser integration
> -Original Message- > From: Gary R. Van Sickle [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 04, 2002 3:51 PM > I took it to mean the opposite - if you uninstalled > *binutils*, it would uninstall gcc because gcc depends on > them. But on further reflection I'm no longer sure even that > is desirable. If I uninstall ash, should say make get > deleted even though I have bash as sh? You should get warned at the very least. I believe that setup should not hinder the power user - such as myself - but should cater for the innocents, those who think "gee I don't use ash, I'll remove it". Potentially bad actions should invoke a warning, with detail about the affected packages, and the ability to a) backout the change (click cancel and ash is left as-is) b) override the automatic behaviour (turn make on and click 'force' and make is left installed) c) accept the default. As for make depending on ash, not on sh, that needs something like debains 'provides' clause, which is on my todo. Rob
RE: [PATCH] Setup Chooser integration
> >>Likewise, if you click ash off, up pops a window listing everything > >>that depends on ash, with an addiotnal message of "Warning: removing > >>ash will cause these packages to be removed as well. > >> > > > >This does make quite a bit of sense to me. But wouldn't MessageBox() > >or something akin to it be a better fit to the task? The only possible > >user input here would be "Yes, remove ash and everything dependent on > >it" and "Cancel", and the only output a list of package names. > > Actually, I think that automatically removing dependencies is not a good > idea. If I select binutils specifically, then select gcc, then uninstall > gcc, I would probably be annoyed to see binutils disappear. > > cgf I took it to mean the opposite - if you uninstalled *binutils*, it would uninstall gcc because gcc depends on them. But on further reflection I'm no longer sure even that is desirable. If I uninstall ash, should say make get deleted even though I have bash as sh? -- Gary R. Van Sickle Brewer. Patriot.
Re: [PATCH] Setup Chooser integration
On Tue, Apr 02, 2002 at 03:14:28PM -0600, Gary R Van Sickle wrote: >> Image: you click on 'install' for 'gcc', and up pops a window >> that lists >> everything that gcc depends on (both requires as we have today, and >> 'suggested' items that aren't always needed but are useful - ie >> autoconf), that was not selected before that click. >> > >I'm drawing a blank at the utility of such a feature, at least in the guise >of a popup of any kind. You're saying that as you go through the dozens of >packages you want and select them, that a box pops up bugging you about the >dependencies of each selection, which you can't do anything about anyways? >That sounds like it would be extremely irritating. Ditto. I also have to admit that I don't see how this corresponds with any complaints or requests that I've seen in the cygwin mailing list. >>Likewise, if you click ash off, up pops a window listing everything >>that depends on ash, with an addiotnal message of "Warning: removing >>ash will cause these packages to be removed as well. >> > >This does make quite a bit of sense to me. But wouldn't MessageBox() >or something akin to it be a better fit to the task? The only possible >user input here would be "Yes, remove ash and everything dependent on >it" and "Cancel", and the only output a list of package names. Actually, I think that automatically removing dependencies is not a good idea. If I select binutils specifically, then select gcc, then uninstall gcc, I would probably be annoyed to see binutils disappear. cgf
RE: [PATCH] Setup Chooser integration
> Gary, I haven't reviewed this yet... > > Can we, with the patch as is, do the following: > > Pop up a chooser? > If you're asking if there's still a do_choose(), the answer is no. Does the patch preclude such functionality? No, but it would require additional code. > That's it. Nice and simple eh? Well, once I've got the > collection based > PickView together, then that should be all there is to it. > > What is this in aid of? > > Image: you click on 'install' for 'gcc', and up pops a window > that lists > everything that gcc depends on (both requires as we have today, and > 'suggested' items that aren't always needed but are useful - ie > autoconf), that was not selected before that click. > I'm drawing a blank at the utility of such a feature, at least in the guise of a popup of any kind. You're saying that as you go through the dozens of packages you want and select them, that a box pops up bugging you about the dependencies of each selection, which you can't do anything about anyways? That sounds like it would be extremely irritating. As for suggestions, mixing them in with dependencies sounds bad to me. Don't the metapackages/"Wokstation/Sever/etc" ideas, however they end up working out, handle suggested packages adequately? > Likewise, if you click ash off, up pops a window listing > everything that > depends on ash, with an addiotnal message of "Warning: > removing ash will > cause these packages to be removed as well. > This does make quite a bit of sense to me. But wouldn't MessageBox() or something akin to it be a better fit to the task? The only possible user input here would be "Yes, remove ash and everything dependent on it" and "Cancel", and the only output a list of package names. > So what I'm asking you now, is if your patch to the chooser > will work in > with this long term plan, or are they orthogonal, or is it a step > backwards? > As I see it, all three: - The long-term plan has to have at least the primary chooser integrated into the Wizard. This patch puts that one to bed. - The changes required to fully implement what you've outlined above are largely orthogonal to the relatively minor changes in this patch. - There's no do_choose() exported anymore, so in that sense you could call it a step back. (You could, I wouldn't ;-)). > I guess we could replace the view in-place within the setup window - > maybe that would be better and cleaner? (Noting that the > PickView class > is heading to be a win32 window with reflector inheriting from your > Window class, so we need some way of removing/hiding the saved window > and then restoring it...) > Microsoft's own installers (e.g. Office) seem to work that way IIRC. Then again I've never been real crazy about their installers - things that seem like they should be "tree-like" aren't (e.g. selecting sub-elements of a package), and things are presented in tree-fashion that don't seem like they should be (selecting the "install/install on demand/don't install"). > Anyway, is this clear as mud? > Hey, if this stuff was easy, anybody could do it. ;-) > Rob > -- Gary R. Van Sickle Braemar Inc. 11481 Rupp Dr. Burnsville, MN 55337 <>
RE: [PATCH] Setup Chooser integration
Gary, I haven't reviewed this yet... Can we, with the patch as is, do the following: Pop up a chooser? That's it. Nice and simple eh? Well, once I've got the collection based PickView together, then that should be all there is to it. What is this in aid of? Image: you click on 'install' for 'gcc', and up pops a window that lists everything that gcc depends on (both requires as we have today, and 'suggested' items that aren't always needed but are useful - ie autoconf), that was not selected before that click. Likewise, if you click ash off, up pops a window listing everything that depends on ash, with an addiotnal message of "Warning: removing ash will cause these packages to be removed as well. So what I'm asking you now, is if your patch to the chooser will work in with this long term plan, or are they orthogonal, or is it a step backwards? I guess we could replace the view in-place within the setup window - maybe that would be better and cleaner? (Noting that the PickView class is heading to be a win32 window with reflector inheriting from your Window class, so we need some way of removing/hiding the saved window and then restoring it...) Anyway, is this clear as mud? Rob
