[REPOST] problem upgrading perl

[Scott Bennett]

     On Tue, 23 Jun 2009 10:30:11 -0700 Doug Barton <dougb at FreeBSD.org>
wrote:
>Scott Bennett wrote:
>>      Thank you for doing that.  Unfortunately, it might have been more
>> appropriate to have simply replaced that note with another that cautions
>> anyone attempting the perl upgrade that the upgrade has not been fully
>> tested against all ports that may list the new perl as a build dependency.
>
>First off, I'm sorry to hear that you're having problems, particularly
>that you're having problems with portmaster.
>
>In regards to the upgrade process not being tested, with over 20,000
>ports it's basically impossible to guarantee that something as
>complicated as upgrading perl will work 100% of the time for every
>user and every combination of perl-dependent ports. I think it's sort
>of a given that "beware of dragons" is posted over the door.
>
>> It should also warn that portmaster is *NOT* a good tool to use for this
>> upgrade, even if the note shows how to attempt it.
>
>I think it depends on your definition of "good," and also how you use
>the tool. Since I use it every day, including for things like
>upgrading perl, I happen to think it's a pretty good tool, but YMMV.
>
>>      Using the specific port name for perl when restarting the upgrade
>> process, I was able to resume for a short time.  However, portmaster has
>> two design problems that apply here.  The first is that if portmaster
>> encounters a port that fails to build properly, it stops cold, rather than
>> continuing to build other ports that do build correctly, summarizing the
>> build errors at the end. 
>
>Because it's impossible for portmaster to know which are the
>"important" errors to a given user I regard this as a feature, rather
>than a problem. Also, errors like the ones you're experiencing
>_should_ be rare, so in general this feature/bug/whatever doesn't
>affect users all that often.

     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".
>
>>      The second design problem is that the -R option, which is supposed to
>> avoid rebuilding ports that have already been successfully rebuilt,
>> nevertheless rebuilds the specified dependency port--in this case,
>> perl-threaded-5.10.0_3--*every single time* without checking to see whether
>> it was already successfully built. 
>
>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.  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

which did rebuild perl (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.
>
>>      Back to the problems with the builds...a half dozen or more port
>> rebuild failures were correctable by simply entering the failed port's
>> directory, doing a "make deinstall && make reinstall", and then returning
>> to restart (again) portmaster, which then, of course, began by rebuilding
>> perl another time (sigh).  Full testing of the perl upgrade should have
>> made this process unnecessary, it seems to me.
>
>Perl is traditionally very twitchy about stuff like this, and the
>solution you used is often the only one possible.
>
>>      Eventually, though, I encountered a problem with a port called
>> misc/gnome-icon-theme-2.26.0_1.  (I do not use and haven't knowingly
>> installed gnome, so I really don't know why this port was installed in
>> the first place. 
>
>pkg_info -R should give you that information.
>
>>      If someone can tell me how to proceed from here, I'll give it another
>> try.  However, once again the ports subsystem is testing my tolerance for
>> frustration, so if there's no real hope of completing the entire rebuilding
>> process for ports with build dependencies upon perl
>
>You should probably use the -i option, and only rebuild the actual p5-
>ports. A lot of ports have what I consider "indirect" dependencies on
>perl that make the -r option for portmaster and portupgrade do more
>work than it probably ought to. However that's a topic for another
>thread. :)
>
     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, but the problems the current tools, dependency
lists, Makefiles, etc. present to the user are often insoluble by anyone but
an expert in the internal workings of each of the pieces of the subsystem.
     The packages subsystem is in about as bad shape, and in spite of the
degree to which the two are intertwined, they really do not play nicely
together.


                                  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         *
**********************************************************************