[REPOST] problem upgrading perl

[Doug Barton]

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.

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

>      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. :)


Good luck,

Doug

-- 

    This .signature sanitized for your protection