In response to Doug Barton <[EMAIL PROTECTED]>: > Bill Moran wrote: > > It's a combination of a number of issues: > > 1) The ports infrastructure shouldn't let you set options that don't make > > sense. > > I think that one could argue that it should be _hard_ to set options > that "don't make sense," but I don't think it should be impossible. you > have to keep in mind that we cater to a very diverse user community, > from rank beginners to advanced hackers.
True. My opinion: A GUI that _prevents_ novice users from selecting incompatible options is a good idea. Expert users can always manually tweak /var/db/ports/ files if they want to override those restrictions. > > 2) Why is portupgrade dying on a warning message? Why does a poor > > decision on one port prevent everything on my system from upgrading? > > For the same reason that portmaster dies on errors, neither program is > omniscient. :) If ports tools hit a point where it's not clear how to > proceed they _should_ stop and get user input. The next thing the users > generally say is that it should "somehow" proceed with the rest of the > upgrade, finish things that don't rely on the broken bits, etc. > Unfortunately that is quite a bit harder to do than you might think, > although patches are always welcome. Understood. But keep in mind that this was not an error, it was a warning. Perhaps the ports infrastructure doesn't differentiate between those two as much as I think. > > 3) The error from portupgrade does not immediately point me to the easy > > solution, it tricks me into thinking I have to hack the Makefile. > > I don't actually think that the error message you're referring to is > from portupgrade, I think it's from the port itself. I can see that. -- Bill Moran http://www.potentialtech.com _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"