On Thu, 25 Jun 2009 10:48:45 -0700 Doug Barton <do...@freebsd.org> wrote: >Scott Bennett wrote: >> On Tue, 23 Jun 2009 10:30:11 -0700 Doug Barton <do...@freebsd.org> >> wrote: >> There ought to be an automated way to deal with the package issue that >> causes the failure of the entire update run just because it wants a human >> to type "make deinstall && make reinstall". > >Sorry I wasn't clear, the inherent problem I described is with perl, >not with the ports. Because perl stores its libraries in a file >hierarchy based on version number (arguably, a feature) when you do a >straight upgrade from one version of perl to another IME the only >really good way to do that is to make a list of perl-related stuff you >have installed, delete everything, and reinstall. For those that only >have a few libraries installed using portmaster/portupgrade -r will >probably work, and is certainly worth a try.
Okay. Thanks for that explanation. How about a cautionary note to that effect in /usr/ports/UPDATING? Maybe a suggestion also that people not attempt the perl upgrade unless they really need the newer version? > >>> Have you tried using the -x option to exclude it? You can also use the >>> -i option, although for a lot of ports that can get annoying. >> >> I had not, thanks to my having misread something in the portmaster man >> page. > >If you have any suggestions for improving the text I'm open to them. No, it reads just fine. I was just in too great a hurry when I looked at it the first time. > >> However, since reading your reply, I have tried (without -R) >> >> # nice +18 portmaster -x perl-threaded-5.10.0 -rv perl-threaded-5.10.0_3 > >If this is a literal copy of what you did I'm surprised it worked >since you've placed the -v option between the -r and its argument. > >> which did rebuild perl > >Yes, I just checked the code and portmaster does not check the -x >argument for the main port specified in the command line. I'll take a >look at that. > >> (along with many other already rebuilt ports, of >> course). At this moment, I have >> >> # nice +18 portmaster -x perl-threaded-5.10.0_3 -R -rv perl-threaded-5.10.0_3 >> >> running, and it is currently rebuilding perl yet again. So the -x option >> appears to be useless, at least in this context. > >You might want to be a little more careful with your adjectives. My >feelings aren't hurt but when you're asking for help, especially for >something you're not paying anything for, words like "useless" tend >not to make you any friends. Oohh, wow. Looks like you got rather more out of my message than I put into it. No offense was intended, I assure you, but rather expression of a sense of disappointment that the FreeBSD project considers implementation of all the latest and greatest networking facilities and features, as well as new stuff in other areas, to the exclusion of fixing the fragility of the ports system for major release after major release. This is not to say anything disparaging about the implementation of all those nice features, even though I doubt that the vast majority of FreeBSD users ever use a lot of them. The ports subsystem is a major part of what makes FreeBSD an option for many people and is very heavily and widely used, so it's a shame to see its problems neglected for so long. > >> I began using FreeBSD at 5.2.1. Along the way, my other complaints have >> largely been fixed, but the ports subsystem remains to this day the weakest >> part of all of FreeBSD. I realize that the problem of coordinating the >> installation and maintenance of such a widely diverse body of ports and >> packages is a complex one, > >Having spent a non-trivial amount of time in the bowels of the ports >system I would argue that "complex" is a dramatic understatement. Ah. Then you do understand why so many of us run into so many problems in trying to use it. Anyway, there is good news to report this time regarding my trials with the perl upgrade. Sometime Thursday afternoon, I appear to have encountered the last "make deinstall && make reinstall" case, after which the upgrade (still using portmaster) ran another five or six hours and completed normally. Many thanks to Sergey Dyatko, Doug Barton, and other respondents for helping me get this done! Now I am left with a couple of questions in dealing with future ports and packages updates. The first is, which is the best tool for doing updates with a preference for using packages rather than rebuilds of ports (a la "portupgrade -aP")? The man page for portmaster doesn't seem to allow a way to use packages at all, even if they are as current as their corresponding ports. The man page for portmanager also shows no option to use packages at all. Is portupgrade the only tool that can do this? My concern is over ports that are infamously painful to rebuild (e.g., openoffice.org, math/atlas). (X.org can also be a bad batch of stuff to rebuild, mostly in terms of the time and space required to do it, but it often does need to be rebuilt in order to get what one needs on a timely basis from Robert Noland's stream (sometimes approaching flood stage) of fixes.) For the moment, I'm holding off from applying updates downloaded by portsnap, but I'd like to resume as soon as I know the best way to go about it. Thanks again to all who helped me with the perl upgrade. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * ********************************************************************** _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"