Maybe helpful hint on newest Perl upgrade

J

jb_fvwm2

Ignore this procedure, skip to the later one...


UPDATING today has a 5.12.4 5.12.5 (etc.) upgrade.

Fix 1: I had to edit the PERL_VERSION manually in /etc/make.conf.
Fix 2: Every time, too many p5-* ports to upgrade.
Fix 2a: A small 3x5 paper to note the failed reinstalls, so they don't delay the entire process. Leave them until later.

The following bit-by-bit (30 at a time) upgrades Perl 5 effortlessly (for the most part). Note that it requires the existence of /var/db/pkg, thus I still am dreading if it (/var/db/pkg) goes away with pkg(ng).

" 12" --todays date. These are skipped (What the hell? --mod)

Const, Glade, one by one add ports that fail to reinstall, left for later.
Code: 
#var/db/pkg# gnuls -oSr | grep p5 | grep -v " 12" | awk '{print $8} | tail -30 | grep -v Const | grep -v Glade | ... | ... | xargs -J % portmaster -d -i -g -B %
At least here, with so many Perl ports installed, this one-liner dispenses with almost all of the upgrade with hardly any typing vs the ways I've done it in the past. [I can't ever use the all-at-once instructions, too much setup each time with multiple restarts (13 failed ports of the hundreds so far, most hardly ever used). ]

Edit:
BTW it inadvertently skipped a slew of them, they will be slower.
 
I have no idea what this is about; I find it hard to fathom what you're even saying here. Maybe your very extremely a-typical way of upgrading ports (keeping all kinds of notes about what, and what not to upgrade, upgrading out-of-order, keeping some things at lower versions) is biting you in the behind? I upgrade Perl routinely, even from 5.12 -> 5.16, and with a recompile of the p5-* ports that depend on it, everything is in working order again. Maybe you should just give up on the idiosyncratic upgrade antics and just keep everything up-to-date as a whole, using a simple daily/bi-weekly portmaster or pkg routine without exceptions, delays, considerations and manual interventions? Because what you describe here never happens to me, and I'm a daily (sometimes twice-daily) updater of ports on all of my systems. I think you're really bringing this on yourself.
 
Thanks for the reply. As the first post method only upgraded about half of them (was based on a method that might have worked better if formulated a bit differently), I here present a slower but working method.

I have 1012 p5-* ports installed, not counting ftime, asciio,... etc. Most of these need moving from 5.12.4 to 5.12 with a reinstall. (In site_perl, which is only half of it.) So the problem becomes how to do 999 of them, saving the failed builds until later AND avoiding tedious restarts. (IOW an hour or two rather than four.)
Code: 
cd /usr/local/lib/perl5/site_perl/5.12.4
cd [some directory]
# I only stumbled upon this bit-by-bit but not TOO slow method a few minutes ago
#  It may be not necc. in other upgrades, now that 5.12.4[5] has been obsoleted
#  in favor of 5.12...
cd Email   # This just did 18 of those...
find . -type f -print0 | xargs -0 pkg_which -v | grep -v "?" | awk '{print $2}' | uniq| xargs -J % portmaster -d -B -i -g %
So at least while it works bit-by-bit, it is seamless, for a whole lot of Perl ports installed.
 
It looks like utter chaos to me. A portmaster -r perl kind of upgrade should be a non-event, not even worth looking at. Which it is when everything is kept up-to-date in the first place. Even with 1000 ports installed. But to each his own. I simply don't think there's much of a wider audience for your descriptions. I don't think anyone will do it this way..
 
It is chaos. A few of the p5-*'s cannot be rebuilt until later in the rebuild cycle... And some fail to fetch or rebuild. These posts are not meant maybe for the wide audience which reads them, just for those who may benefit from the hints within the CLI I've posted. And apologies for wasting the time of those who read the posts and have no use for any solutions presented. Not my intent to waste anyone's time, unintentional consequence of the posts.

[ This method BTW may be useful if one, say, upgrades Python 26 > 27 ] and that reminds me, I will save this thread to the Python port directory so I don't muddle through those upgrades.

Email: 2 minutes
Eval: 1 minute
Net: 3 minutes (maybe)
each with just a keyboard up-arrow if the previous instructions are added onto...
Code: 
... && cd /usr/local/lib/perl5/site_perl/5.12.4
so the cursor is placed ready to change to the next subdirectory.
 
I think the whole issue can be easily summed up: use portmaster in the way it was intended. Although I have absolutely no idea what kind of problem is being mentioned here (and I'm not really interested to dive deeper into this) I can say that portmaster has an option to counter any problem you mentioned here.

It starts with the "too many updates", if you use the -a option it doesn't really matter how many there are.

Using xargs to provide data to portmaster is messed up when dealing with updates. Because one of the key features of portmaster is that it can calculate dependencies and make sure that those are met. Obviously it won't be able to properly do that if you only feed it a selection of the ports you need to update, almost certainly resulting in errors (depending on the ports involved of course).

It seems to me that this is exactly what is happening on your end given to your comment regarding ports which can only be rebuild in a specific order (in other words: need to have certain dependencies satisfied first).

In fact; the xargs comment alone makes me wonder if you actually realize that the glob used by portmaster might not be a regular expression, it can still easily deal with multiple selections.

So if I were to re-install (or update) all "p5 ports" on my system all I would need is: # portmaster p5 and let portmaster sort it all out. Don't take my word for it, just take a look yourself by using: $ portmaster -n p5 and see what happens.

Don't worry: the -n flag makes sure that it will only show you what it's going to do without actually doing it. You can even execute this as a regular user in order to make sure that nothing will be changed.
 
They do not, however, all reinstall cleanly. (po4a, for example, is today unfetchable; p5-AnyData will not readily build, p5-B-Utils does not build unless many others built before it; two ports were deprecated and had to be deinstalled; etc. [ And with sending them all to portmaster at once, "you can restart with..." is not so simple. (Some to ignore, the ones that have already been done (for instance, 400 done, 600 remaining...) have to be rebuilt ONLY. Portmaster is not yet, but could be, smart enough to have more fine-grained control over a large upgrade like this IMHO. ]

OTOH with the recent method I posted above, all four p5-Template-* rebuilt in precisely 23 seconds, and I could proceed to the next subdirectory in site_perl/5.12.4, repeat the command without retyping (up arrow on the keyboard...) and have a list of ports to ignore for now as an aside. And maybe someday could use the one-liner above wrapped in a perl-after-upgrade of sorts.

Most rebuilt, finally. One port was deinstalled because of a conflict (new dependency). Three ports were deinstalled because a dependency was deprecated. p5-HTML-Template-Pro, PDL, p5-Mail-CClient won't build for now. p5-File-Map, though, newly DOES build.

There are probably ports without p5 in their name which need rebuilding, but no time for now.
 
jb_fvwm2 said:
They do not, however, all reinstall cleanly. ( po4a, for example, is today unfetchable; p5-AnyData will not readily build, p5-B-Utils does not build unless many others built before it; two ports were deprecated and had to be deinstalled; etc.
[And with sending them all to portmaster at once, "you can restart with..."
is not so simple. (Some to ignore, the ones that have already been done (for instance,
400 done, 600 remaining...) have to be rebuilt ONLY. Portmaster is not yet, but
could be, smart enough to have more fine-grained control over a large upgrade like
this... IMHO.]
Click to expand...
I think it has.

First; no matter what kind of (supported) upgrade procedure you'll use; there are going to be times when an upgrade will fail due to errors. It's a given and I fully agree with you that such scenario's aren't all that easy. Most certainly not!

But working around those scenario's can be. For example, you mentioned textproc/po4a, devel/p5-AnyData and devel/p5-B-Utils. I can reproduce the problems with textproc/po4a (but it wouldn't matter if I couldn't, I've been there myself several times as well) but that's where -x can help you out; used to exclude certain ports from building or updating.

This will at least make sure that there won't be any inconsistencies as well as avoiding that you're going to build ports multiple times; something which could easily happen if you install ports one by one, while two of them rely on a same port.

Another option you should consider is -R:

Code: 
===>>> There are 'install complete' flags from a previous
       -[rf] run of portmaster, delete them? y/n [n]
portmaster can mark an updated or installed port as 'complete' so that it will skip them if you need to run it again. The reason I could paste this is because I upgraded Perl on my system last night, and when an upgrade session involves dozens of ports I always use this flag.

You don't need to manually exclude ports which you already upgraded when you need to start the process again; portmaster has your back.

jb_fvwm2 said:
OTOH with the recent method I posted above, all four p5-Template-* rebuilt in precisely 23 seconds, and I could proceed to the next subdirectory in site_perl/5.12.4, repeat the command without retyping (up arrow on the
keyboard...) and have a list of ports to ignore for now as an aside.
Click to expand...
Each to his own, but I honestly think you've cooked up a recipe for a possible disaster.
 
I must completely agree with @DutchDaemon. Keep your systems up to date. And even so, don't do things like

jb_fvwm2 said:
...
Fix 1: I had to edit the PERL_VERSION manually in /etc/make.conf.
...
Click to expand...

but consider using -o flag instead, or manually inserting the port path as an argument to portmaster, e.g. # portmaster -r /usr/ports/lang/perl5.14, or whichever version of perl you're using.

If you are experiencing similar problems for a longer period of time, consider rebuilding all of your ports, with # portmaster -afy or # portupgrade -af (which you should've done if you upgraded to a different major version of FreeBSD).
 
Last edited by a moderator:
jozze said:
If you are experiencing similar problems for a longer period of time, consider rebuilding all of your ports, with # portmaster -afy or # portupgrade -af (which you should've done if you upgraded to a different major version of FreeBSD).
Click to expand...
You might also want to use -R in those cases since that will allow portmaster to automatically skip already processed ports. Depending on the environment this can be very handy if you need to start the process multiple times.
 
Maybe it's because everybody uses ports-mgmt/portmaster, that I only see reports with this lang/perl update, or it's merely because people don't keep their ports up to date. I am using ports-mgmt/portupgrade, and I didn't have any problems, even when lang/ruby19 was updated, and ports-mgmt/portupgrade itself depends on it.

Next time, even if UPDATING says you don't have to, check if it is a library that many ports need, and consider using the -r flag just in case (to compile all the ports that depend on that port), or the -R flag. Sure, things will run even without it, but they may not necessarily rebuild. Especially if you are changing settings in your /etc/make.conf all the time. I think it's important, that the ports are coherent, so you don't have mismatched or non-existent headers and stuff like that.
 
I didn't have all the problems the OP alluded to, but a simple portmaster -r perl didn't quite do it either. For example graphics/opencv and related ports failed to compile. It turned out that since I have both python2 and python3 installed, and /usr/local/bin/python is a link to python2, I had to temporarily delete the link to get these to install successfully. There were a few other minor hiccups, but overall portmaster did pretty well since it involved over 500 ports on my laptop. I update the ports each night and usually it only takes a few minutes. If it takes more I just let it run overnight.
 
Well, I've all the .tbz from one machine ready for portmaster to use on another, but it errors out on each usage. The following is slow:
Code: 
# but working
cd /usr/local/lib/perl5/site_perl/5.12.4
cd Archive
find . -type f| xargs -J % pkg_which | xargs -J % portmaster -d -B -P -i  -x gcc-4.7.3.20136323 -R %  && cd /usr/local/lib/perl5/site_perl/5.12.4 
#  if Archive is fully updated, it will be gone, one can change into the next A... etc
Not wishing to post this as wanting a fix, I think portmaster needs a whole new switch so it can automate that, no combination accomplishes the same without some error message, at least with so many hundreds of ports needing updating but without too many restarts. This way, each possibility of error (each portmaster run) only affects a few ports, so the restart is more precise, and just the entire process is lengthy.

edit... it gets worse! or better!
I ran the pipe-command from a level higher (and embellished with code before it) and it started to update too many non-relevant ports. I cntl-c'd that, it would not end. So as I type this, it is unstoppably updating all or most (unknown at this point) as I wanted it to in the first place, but this time without operator intervention.
..../end edit/....

[size=-1]But as seen above (and thanks to one of the posts in this thread, using the -R means that this CLI operates so swiftly (3-10 seconds per application, archive etc) that one can complete it in record time, albeit not the ideal solution.[/size]

(In this instance, .tbz already present and in /usr/ports/packages/portmaster-download/) [Sorry for the not-usually-relevant procedure].
 
You must log in or register to reply here.
Back
Top