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: 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/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,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


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