Another PHP pkg upgrade problem

I've read a few other threads about this, but I haven't found one that has what seems like a solution for the specific issue I'm having.

I'm running into the problem with PHP updating to 5.6, causing package conflicts. Specifically, this:

Code:
pkg: Cannot solve problem using SAT solver:
conflict rule: The following packages conflict with each other: php5-xml-5.4.39(r), php56-xml-5.6.7(r)
dependency rule: package cacti(l) depends on: php5-xml(r)php5-xml(l)
upgrade rule: upgrade local php5-xml-5.4.27 to remote php5-xml-5.4.39

I could remove and re-install all of the PHP packages, but the problem is that it will also remove things that depend on PHP, namely cacti. I believe that when cacti is removed, it will also remove all of my local cacti configs, which I really don't want to have to recreate. I suppose I could try to figure out which files have local data in them and manually copy them back in after removing and reinstalling, but that seems very error prone. Surely there has to be a better way to deal with this.

Is there some way to force remove and reinstall every php package without removing the dependencies? Any other idea?
 
I should note, I don't particularly care which version of PHP I have. This is an internal machine, and the sole reason it even has PHP is for cacti. As long as cacti continues to work, I'm happy. So a solution that either pins PHP to 5.4.x, or a solution that makes the upgrade to 5.6.x without breaking cacti, are both equally fine with me.
 
It looks like net-mgmt/cacti relies on lang/php56. I would think if you just did a pkg upgrade that would account for the change. Selectively trying to upgrade just PHP would likely not work right now. Are you upgraded everything at once or just PHP?
 
That's what happens when I just do a pkg upgrade.

Something else weird is happening, because if I try to individually upgrade something, it wants to remove a bunch of seemingly unrelated stuff. E.g. pkg upgrade -n rrdtool wants to remove devel/git among other things:

Code:
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking integrity... done (5 conflicting)
Checking integrity... done (0 conflicting)
The following 120 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
    mediatomb-0.12.1_11
    ntop-5.0.1
    ghostscript9-9.06_5
    m17n-lib-1.6.4_1
    emacs24-24.3_2,3
    webp-0.3.1_4
    ImageMagick-6.8.0.7_5,1
    apache22-2.2.27_1
    ldb-1.1.16
    ntopng-1.1_1
    subversion-1.8.8_1
    minidlna-1.1.1_5,1
    ffmpeg-2.1.1_1,1
    ffmpegthumbnailer-2.0.8_2
    git-1.9.2

New packages to be INSTALLED:
    i386-wine: 1.6.2_9,1
    indexinfo: 0.2.3
    gettext-runtime: 0.19.4
    trousers-tddl: 0.3.10_7
    db5: 5.3.28_2
    apache24: 2.4.12
    libxshmfence: 1.1_3
    libglapi: 10.4.6
    libdevq: 0.0.2_1
    gettext-tools: 0.19.4

<snip>

I saw this thread, Thread pkg-wants-to-remove-certain-packages.48711, which suggested pkg update -f followed by pkg check -Ba but that didn't resolve the problem.
 
The versions of devel/git and devel/subversion shown peg things at around March/April of last year. Trying to update single packages when there have been so many changes since last year won't work out very well. The safest thing you can do is to upgrade everything at once. Read and heed /usr/ports/UPDATING. Get the list of everything you explicitly installed with pkg query -e '%a = 0' %o. Then get some downtime and run pkg upgrade or even pkg upgrade -f and verify everything you had explicitly installed in the past has been satisfied. A pkg autoremove when done would likely be warranted to remove anything unneeded at that point.
 
A full pkg upgrade fails with the dependency error I started the thread with. I am not trying to upgrade things individually; I just showed that as an example.

Code:
$ sudo pkg upgrade
Password:
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (206 candidates): 100%
Processing candidates (206 candidates): 100%
Checking integrity... done (13 conflicting)
pkg: Cannot solve problem using SAT solver:
conflict rule: The following packages conflict with each other: php5-xml-5.4.39(r), php56-xml-5.6.7(r)
dependency rule: package cacti(l) depends on: php5-xml(r)php5-xml(l)
upgrade rule: upgrade local php5-xml-5.4.27 to remote php5-xml-5.4.39
cannot install package php5-xml, remove it from request? [Y/n]: 
pkg: cannot find php5-xml in the request
pkg: cannot solve job using SAT solver
Checking integrity... done (0 conflicting)
Your packages are up to date.
 
Any luck? The same basic advise as before is still prudent here. Things are very far out of date and pkg() still has some troubles with that situation. As said before, the safest thing you can do is to upgrade everything at once. Read and heed /usr/ports/UPDATING. Get the list of everything you explicitly installed with pkg query -e '%a = 0' %o. Then get some downtime and run pkg upgrade or even pkg upgrade -f and verify everything you had explicitly installed in the past has been satisfied. You may have to do something like a pkg delete php5-xml to get things into a state where the solver can satisfy everything in the request and the pkg upgrade actually works. Once you upgrade, just install it again for the latest version. The pkg autoremove when done would likely be warranted to remove anything unneeded at that point.
 
No luck yet, but I've been too busy to block out the time to really fix this. I think it's going to take a while, primarily to handle the stuff that gets deleted. Like I said in the original post, the primary issue here is Cacti, which has a bunch of local config and data that I don't want to lose or re-create. It appears that all of that stuff gets deleted when the Cacti package gets removed. And removing php5-xml also causes Cacti to be removed. I just have to spend the time to untangle which files need to be preserved to avoid losing data before I can do this. Once I do that I can just nuke ALL of the php5 and apache stuff and start clean with it, I think.

The good thing is it's all on zfs so I can do a snapshot and if everything gets screwed up I can reverse it. But I still need to make sure I have the time available to actually fix it once I start...

Thanks for the help so far!
 
Back
Top