[pkgng] replacement for perl-after-upgrade

mix_room · Nov 8, 2012

Previously when I updated perl from one version to the next I would run # perl-after-upgrade which would take care of updating all dependent packages aswell.

According to /usr/ports/UPDATING I should now run # pkg install -fRx perl instead.

However, when I do this it wants to downgrade a lot of installed packages to the last binary one:

Code:

Downgrading firefox: 16.0.2,1 -> 15.0.1,1
Downgrading libreoffice: 3.5.7 -> 3.5.6_1
Downgrading p5-subversion: 1.7.7 -> 1.7.6
Downgrading feh: 2.7 -> 2.6.1

I do not want to downgrade anything. Is there a more suitable replacement than reinstalling all the binaries, and then recompiling everything to get an upgrade?
There seems to be something lacking in the new package systems when a previously simple thing becomes VERY complicated. I am thus assuming that I am doing something wrong.

jb_fvwm2 · Nov 8, 2012

I sympathize here; hesitant to begin usage of pkg until other users submit solutions to problems such as this one. I've posted as such to the freebsd-ports list quite a few times...

break19 · Nov 9, 2012

The solution is, use either ports.. or packages.. so that your versions stay in sync.

jb_fvwm2 · Nov 9, 2012

That is easy to say, but difficult to do... I've several machines that can use packages but not ports, but pkgng would complicate their updates. Furthermore, ports and packages work fine for the few cases that the package updates fail.
At any rate, I encourage anyone and everyone to subscribe to the freebsd-ports list; it seems about half of the problems with pkg are reported here; half there; and the few such as I who do not wish /var/db/pkg etc to be obsoleted would prefer to just follow along rather than have to post in one place or the other when the status quo is known, and more importantly proven to "just work" at least here; and so have little to add to further developments, not so much for lack of time, but each post or question lacks background (the mailing list posts in these threads, or these threads at the mailing list...)

mix_room · Nov 12, 2012

break19 said:
The solution is, use either ports.. or packages.. so that your versions stay in sync.

That is not a solution, that is a workaround.
In any case packages are just binary version of the ports, so I don't see how this affects anything.

mix_room · Nov 12, 2012

What I am trying now is from an older entry in /usr/ports/UPDATING

Code:

20120630:
...
    2) Reinstall everything that depends on Perl:
	portupgrade -fr perl
...

chrcol · Jun 25, 2013

What's the reason for the removal of perl-after-upgrade? It was only added a few years back and has been extremely useful.

portupgrade -fr perl is doing nothing for me, it just exits back to the prompt.

zeissoctopus · Jun 25, 2013

mix_room said:
According to /usr/ports/UPDATING I should now run # pkg install -fRx perl instead.

However, when I do this it wants to downgrade a lot of installed packages to the last binary one:

Which PKGNG repository do you use? Are you sure you use a repository which has rebuilt all PKGNG packages from the nightly snapshot of the ports tree?

jozze · Jun 25, 2013

chrcol said:
whats the reason for the removal of perl-after-upgrade? it was only added a few years back and has been extremely useful.

portupgrade -fr perl is doing nothing for me, it just exits back to the prompt.

Because portupgrade doesn't read perl as portmaster does. You have to manually specify which port your perl installation is. You can see which version you use with # grep PERL /etc/make.conf. I use 5.14.4, so I ran # perl -rf lang/perl5.14.

ericx · Jul 6, 2013

Having just upgraded to Perl 5.16.x, this provides a list of all ports with files listed in the PKGNG database containing the string "perl5" but not "5.16". Note that this is really just a suggested list of things that should be upgraded because, for example, "perl" itself appears (i.e. Perl itself installs the file /usr/local/bin/perl5 and that matches the greps.

pkg query -a "%n %Fp" | grep perl5 | grep -v 5.16 | awk '{print $1}' | uniq

ericx · Jul 6, 2013

[doh...]

Better: pkg query -a "%n %Fp" | grep site_perl | grep -v 5.16 | awk '{print $1}' | uniq

phoenix · Jul 7, 2013

mix_room said:
That is not a solution, that is a workaround.
In any case packages are just binary version of the ports, so I don't see how this affects anything.

Ports are always newer than packages. packages are only built now and then, based on what's in the ports tree at that point in time, using the default options.

Mixing ports and packages is not recommended.

Chris_H · Jul 13, 2013

chrcol said:
What's the reason for the removal of perl-after-upgrade? It was only added a few years back and has been extremely useful.

portupgrade -fr perl is doing nothing for me, it just exits back to the prompt.

Because (as /usr/ports/UPDATING indicates) the FreeBSD install process will no longer rely on patchlevel when dealing with the install/upgrade process. It now only concerns itself with major.minor for th(is|ese) operations. Have a look in /usr/local/lib/perl5. Instead of a subdirectory of 5.12.14, you'll now only have 5.12.

Hope this helps, and do know I share your pain. I also had quite a battle trying to reconcile all of my installed modules after this.

--chris

tingo · Jul 14, 2013

I ran into this annoying issue this evening. Thanks to post #9, I knew what to do (# portupgrade -rf lang/perl5.12), but the lack of perl-after-upgrade is still annoying.

If anyone has a workaround for portupgrade users (see post 10 and 11 in this thread), please share.

jb_fvwm2 · Jul 14, 2013

In response to post #14, this method has sufficed well, but it requires some expertise, practice, and setup. Note that one should upgrade perl beforehand and also edit make.conf ... and that there are multiple directories in which to repeat the command (not typing it again of course...) so it is adjusted often. However, one can reinstall five or ten or twenty ports at a time with portmaster, so while it takes way longer, restarts and continuations are easy. I'd advise if one tries this method, to do other things in the meantime in the vicinity so as to not be wasting time.

Code:

cd /usr/local/lib/perl5/site_perl/5.12.4/Algorithm  (or Any, or AnyData,...)
find . -type f -print0 | xargs -0 pkg_which -v | grep -v "?" | awk '{print $2}' | uniq | xargs -J % portmaster -d -B -i -g % && cd /usr/local/lib/perl5/site_perl/5.12.4  (repeat for each subdirectory).

Of course one could modify it to run quicker, all-at-once if one has only a few hundred perl dependent ports installed.

This way uses portmaster though, I've not tested portupgrade with it yet, that would take more time...

ericx · Sep 5, 2015

Old thread; but still a bit of a problem.

perl modules currently mostly install themselves in site_perl rather than site_perl/[version]. This is an improvement. However, many still install themselves in site_perl/mach/[version] and these ports fail to run after an upgrade to perl. Note also that not everything found in site_perl/mach/[version] is code. A lot of it is merely .packlist.

Here's my current work-around to rebuild only those modules which will break. This example is after an upgrade from 5.20 to 5.22:

 portmaster $(pkg query -a "%n %Fp" | grep site_perl | grep 5.20 | grep -v packlist | awk '{print $1}' | uniq | tr "\n" " ")

The above should probably work for portupgrade too; but I haven't tried it.