Solved Cannot solve problem using SAT solver

Hello,

When upgrading using pkg upgrade, it ended up with this:

Code:
Proceed with this action? [y/N]: y
Fetching php5-extensions-1.7.txz: 100%  1 KiB  1.1kB/s  00:01
Checking integrity... done (27 conflicting)
pkg: Cannot solve problem using SAT solver:
conflict rule: The following packages conflict with each other: php5-zlib-5.4.38(r), php56-zlib-5.6.6(r)
dependency rule: package php5-zlib(r) depends on: php5-zlib(l)owncloud(l)
dependency rule: package php5-zlib(r) depends on: php5-zlib(l)php5-extensions(l)
conflict rule: The following packages conflict with each other: php5-zlib-5.4.38(r), php5-zlib-5.4.38(r)
upgrade rule: upgrade local php5-zlib-5.4.37 to remote php5-zlib-5.4.38
cannot install package php5-zlib, remove it from request? [Y/n]: Y
pkg: cannot find php5-zlib in the request
pkg: cannot solve job using SAT solver
Checking integrity... done (0 conflicting)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
# pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (52 candidates): 100%
Processing candidates (52 candidates): 100%
Checking integrity... done (27 conflicting)
pkg: Cannot solve problem using SAT solver:
conflict rule: The following packages conflict with each other: php5-zlib-5.4.38(r), php56-zlib-5.6.6(r)
dependency rule: package php5-zlib(r) depends on: php5-zlib(l)owncloud(l)
dependency rule: package php5-zlib(r) depends on: php5-zlib(l)php5-extensions(l)
conflict rule: The following packages conflict with each other: php5-zlib-5.4.38(r), php5-zlib-5.4.38(r)
upgrade rule: upgrade local php5-zlib-5.4.37 to remote php5-zlib-5.4.38
cannot install package php5-zlib, remove it from request? [Y/n]: Y
pkg: cannot find php5-zlib in the request
pkg: cannot solve job using SAT solver
Checking integrity... done (0 conflicting)
Your packages are up to date.

At the end it says that packages are up to date although nothing has been updated. Moreover, if I run pkg upgrade once again after this last message:

Code:
# pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (52 candidates): 100%
Processing candidates (52 candidates): 100%
Checking integrity... done (27 conflicting)
pkg: Cannot solve problem using SAT solver:
conflict rule: The following packages conflict with each other: php5-zlib-5.4.38(r), php56-zlib-5.6.6(r)
dependency rule: package php5-zlib(r) depends on: php5-zlib(l)owncloud(l)
dependency rule: package php5-zlib(r) depends on: php5-zlib(l)php5-extensions(l)
conflict rule: The following packages conflict with each other: php5-zlib-5.4.38(r), php5-zlib-5.4.38(r)
upgrade rule: upgrade local php5-zlib-5.4.37 to remote php5-zlib-5.4.38
cannot install package php5-zlib, remove it from request? [Y/n]:

I have seen there's something about the new default version of php in /usr/ports/UPDATING, but it doesn't mention this error.

I have found a similar thread, where the author mentioned that unlocking all ports did solve the error. As I lock some ports indeed, I tried this too, but I always get the error messages. (The two code portions above show up after pkg update and pkg upgrade with no ports locked.)

Any help?
 
In Thread another-question-about-rebuilding-all-3d-party-software.50440/ you mentioned
I installed most of my packages using pkg; could I rebuild with portmaster only the few ones that have been installed with portmaster, all others with pkg-static?
May be there are issues now because of using packages and ports. Have you already updated all ports related to lang/php? I am no expert in mixing ports and packages, may be you will have to change everything to ports. But may be some more experienced user will have a better advise.
 
Hi quamenzullo,

No offense, but from your previous posts, your package management technique is a bit of a mess ;). You cannot put locks all over the place (like here), mix ports and packages and expect pkg(8) to work smoothly. The best advice you can take is the one chrbr just gave you.

Could you give us the output of pkg info | grep php ?

chrbr said:
I am no expert in mixing ports and packages, may be you will have to change everything to ports. But may be some more experienced user will have a better advise.
You are right, it as been said somewhere else already.
 
Hello,

First of all, many thanks for the answers. I'm trying to understand better how this all works.

I wanted first to use only pkg, but I needed to change the configuration for three packages:
lang/php5-extensions,
lang/php5,
ftp/proftpd.

So, inspired by this: Thread dual-mode-maintenance-of-ports-and-packages.47742, I have decided to let pkg manage everything but the three ports mentioned above (that I lock while pkg is working) and let portmaster manage these three ports.

So far I have read several diverging opinions about mixing ports and packages or not. I would prefer to stick to this organization (only three ports managed by portmaster instead of pkg), unless it is really impossible, because there are some ports I really would avoid to compile. I used to use portmaster only, also had lots of problems...
hukadan said:
You are right, it as been said somewhere else already.
As far as I understand this, this is not about mixing packages and ports, but about mixing local and remote repository sources.

Anyway, something is clearly wrong in my ports/packages:
Code:
# pkg info | grep php
php5-5.4.38  PHP Scripting Language
php5-bz2-5.4.37  The bz2 shared extension for php
php5-ctype-5.4.37  The ctype shared extension for php
php5-curl-5.4.37  The curl shared extension for php
php5-dom-5.4.37  The dom shared extension for php
php5-exif-5.4.37  The exif shared extension for php
php5-extensions-1.7  "meta-port" to install PHP extensions
php5-fileinfo-5.4.37  The fileinfo shared extension for php
php5-filter-5.4.37  The filter shared extension for php
php5-ftp-5.4.37  The ftp shared extension for php
php5-gd-5.4.37  The gd shared extension for php
php5-gettext-5.4.37  The gettext shared extension for php
php5-hash-5.4.37  The hash shared extension for php
php5-iconv-5.4.37  The iconv shared extension for php
php5-json-5.4.37  The json shared extension for php
php5-ldap-5.4.37  The ldap shared extension for php
php5-mbstring-5.4.37  The mbstring shared extension for php
php5-mcrypt-5.4.37_1  The mcrypt shared extension for php
php5-mysql-5.4.37  The mysql shared extension for php
php5-mysqli-5.4.37  The mysqli shared extension for php
php5-openssl-5.4.37  The openssl shared extension for php
php5-pcntl-5.4.37  The pcntl shared extension for php
php5-pdo-5.4.37  The pdo shared extension for php
php5-pdo_mysql-5.4.37  The pdo_mysql shared extension for php
php5-pdo_sqlite-5.4.37_1  The pdo_sqlite shared extension for php
php5-phar-5.4.37  The phar shared extension for php
php5-posix-5.4.37  The posix shared extension for php
php5-readline-5.4.37  The readline shared extension for php
php5-session-5.4.37  The session shared extension for php
php5-simplexml-5.4.37  The simplexml shared extension for php
php5-sqlite3-5.4.37_1  The sqlite3 shared extension for php
php5-tokenizer-5.4.37  The tokenizer shared extension for php
php5-wddx-5.4.37  The wddx shared extension for php
php5-xml-5.4.37  The xml shared extension for php
php5-xmlreader-5.4.37  The xmlreader shared extension for php
php5-xmlwriter-5.4.37  The xmlwriter shared extension for php
php5-xsl-5.4.37  The xsl shared extension for php
php5-zip-5.4.37  The zip shared extension for php
php5-zlib-5.4.37  The zlib shared extension for php

Everything is about 5.4, although the default version now is 5.6. The first error messages mention a conflict between a 5.6 package and a 5.4 one.

So maybe it would be worth trying to tell portmaster to remove all what is related to 5.4 and install the 5.6 versions instead? I just don't know how to do it in a clean way.
 
quamenzullo said:
As far as I understand this, this is not about mixing packages and ports, but about mixing local and remote repository sources.
Well, you are right about the context. But IMHO, the fact that you build packages with different port tree version is what matters. So, I expect this to apply also when mixing ports and packages.

I am sorry but I do not use portmaster(8) and therefore cannot help you much with it. I build a local repository using poudriere(8) and use it with pkg(8). But, if you want to reinstall everything using portmaster(8), the procedure at the end of portmaster(8) is apparently outdated (see this post). This is the new version in patch form (ignore the lines starting with minus sign).
 
It's difficult to find informations about the underlying mechanisms of pkg and portmaster. I have read they use the same database, but I would like a confirmation.

Also, https://wiki.freebsd.org/pkgng states that:

What it is not
pkgng is not:

  • a replacement for portupgrade/portmaster
What it is
pkgng is:

  • the new package management tool for ports and binary packages

So, this lets me think that pkgng is the management tool for both ports and packages, and so that tools like portmaster rely on it too, or at least use the same data? (I think I have read something like that already, somewhere). (Also, notice that pkg info in my previous post gives informations about ports that have been built using portmaster and not pkg).

Maybe poudriere(8) would be a solution for me, instead of mixing ports and packages. I will read more about it.

Anyway I still wonder why, when /usr/ports/UPDATING mentioned that php's default version was set to 5.6 instead of 5.4, the update I've done finished correctly (no error) but php is still 5.4. Is it normal? Can anyone give a hint about how I can properly tell portmaster to update it to 5.6?
 
It's difficult to find informations about the underlying mechanisms of pkg and portmaster. I have read they use the same database, but I would like a confirmation.

Also, https://wiki.freebsd.org/pkgng states that:

So, this lets me think that pkgng is the management tool for both ports and packages, and so that tools like portmaster rely on it too, or at least use the same data? (I think I have read something like that already, somewhere). (Also, notice that pkg info in my previous post gives informations about ports that have been built using portmaster and not pkg).

Maybe poudriere(8) would be a solution for me, instead of mixing ports and packages. I will read more about it.

Anyway I still wonder why, when /usr/ports/UPDATING mentioned that php's default version was set to 5.6 instead of 5.4, the update I've done finished correctly (no error) but php is still 5.4. Is it normal? Can anyone give a hint about how I can properly tell portmaster to update it to 5.6?

They don't really use the same database anymore, ports-mgmt/portmaster no longer knows anything about the internals of the packaging system so the whole package database and its details are out of its scope. The ports-mgmt/pkg tool is used as a backend for performing package registration when a port build finishes and after the package registration an installed port is just another installed package, you can't tell apart a package installed from ports from a package installed as binary package using pkg-install(8).

The reason for this misleading "they use the same database" information is that the old package database was a simple, crude, fragile (very fragile, it didn't even have a single method for maintaining internal consistency), non-scalable text database stored in many files and ports-mgmt/portmaster was created to address many of the shortcomings of this database. It was for example able to fix many of the dependency related problems in the package database that you couldn't easily fix otherwise. Now that the package database is stored as proper database these features relating to the handling of the package database no longer work and are not needed.
 
Finally it seems to be solved, but I don't know exactly how neither what was the cause of the problem.

In case this may help: I didn't upgrade to php56 and as I noticed pkg was trying to do something with these php5-* packages I don't want him to manage anyway, I explicitly locked them; plus I uninstalled owncloud, which maybe was causing the error by requiring some php extensions in a specific version (this is just a guess). Now the php extensions are unlocked again and everything seems to be fine.

And really I might have to try poudriere(), though it seems a big thing to only get php-fpm working (this is by default not enabled in lang/php5 config).

So, done.
 
Back
Top