# [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: 

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


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


----------



## chrcol (Jun 25, 2013)

*W*hat*'*s the reason for the removal of perl-after-upgrade? *I*t 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_ port_s_ 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 _P_erl 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. _P_erl 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:
			
		

> *W*hat*'*s the reason for the removal of perl-after-upgrade? *I*t 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. *I*nstead 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. 

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


----------

