pkg wants to reinstall over port

vaskark

vaskark

Hello. New user here.
I recently switched to the latest branch of 12.2-RELEASE-p4 and updated all my installed pkgs. Then, I installed the port system because I wanted a version of berry (x11-wm/berry) with my own patches applied. All of it worked exactly as planned and installed fine.
However, the next time I ran sudo pkg upgrade I received this message:

Code: 
Installed packages to be REINSTALLED:
          berry-0.1.7 (options changed)
Number of packages to be reinstalled: 1

This would obviously override my custom port. Shouldn't my port take precedence over a pkg?
Any help/advice would be greatly appreciated.
Thanks.

Code: 
uname -a: FreeBSD freebsd 12.2-RELEASE-p4 FreeBSD 12.2-RELEASE-p4 GENERIC amd64
pkg -v: 1.16.3
 
There is no difference between a port and a package. Ports build packages and a package is just a pre-compiled port. If there's a newer version then it's going to get updated, regardless if you previously built it from a port or installed it as a package.
 
Thanks for the quick reply.
So basically I have to reinstall the pkg and then reinstall my custom port every time that berry is updated?
Ah.

Edit: Wait. I just rebuilt and installed my custom port again. And it wants to reinstall berry again, but it hasn't been updated.
 
pkg lock is your friend when you need specific options for a port. Building the port actually created a local "package" which then got installed on your system. pkg lock <package> tells pkg not to touch that one, ever, if there's a difference between what is installed locally and what is in the FreeBSD pkg repository.
 
vaskark said:
I just rebuilt and installed my custom port again. And it wants to reinstall berry again, but it hasn't been updated.
Click to expand...
Did you add or remove options in your custom port? Because the message is claiming the options changed.
 
pkg-lock(8) comes with perhaps undesired consequences.
from the given man page: said:
The impact of locking a package is wider than simply preventing modifications to the package itself. Any operation implying modification of the locked package will be blocked. This includes:
  1. Attempts to reinstall, up- or downgrade or delete the locked package itself.

  2. Installation, up- or downgrade of a package where the resultant package would have a dependency on a different version of the locked package.

  3. Deletion, up- or downgrade of any package the locked package depends upon, either directly or as a consequence of installing or upgrading some third package.
Click to expand...
You want 1. and get 2. and 3. as well.

When I established my dual mode maintenance mechanism of ports/packages several years ago, I experimented a lot with locking and unlocking of some ports, but I never got it to work by that way without issues — see my old post on this: https://forums.freebsd.org/threads/dual-mode-maintenance-of-ports-and-packages.47742/#post-267970

What worked well for me since several years on many systems now, is to maintain a list of ports with customized options. Then this list is used by the software update script for dividing the list of outdated ports into a list to be updated by pkg update <pkglist> and another list to be updated by port building.

The whole idea and said script is written up here: https://obsigna.com/articles/1519780374.html
 
Alternatively, you can just increase the PORTREVISION of the custom port. That will make it newer than the version that's in ports. But keep in mind that if the version of application actually changes that would mean it's newer and it'll get upgraded again. But it's always a good idea to keep an eye on the list of packages before actually committing to the upgrade.
 
The elegant solution for this problem would be to build your own local repository and configure it for pkg with a higher priority than the official one.

Unfortunately, as of now, ports-mgmt/poudriere has to build all dependencies in order to build a package, and they will all end up in the repository built. There are two pull requests for changing that: #797 and #798.

AFAIK, ports-mgmt/synth already has these features, but I'm not sure and have no experience with it.
 
SirDice said:
Alternatively, you can just increase the PORTREVISION of the custom port. That will make it newer than the version that's in ports. But keep in mind that if the version of application actually changes that would mean it's newer and it'll get upgraded again. But it's always a good idea to keep an eye on the list of packages before actually committing to the upgrade.
Click to expand...
I think this works best for me. Thanks for the advice.
 
You must log in or register to reply here.
Back
Top