Solved pkg update dependency question

Hi,
I am running amd 10.3 release that has been updated to p19 using freebsd-update. All of the applications that have packages have been installed using pkg install and updated using pkg upgrade. perl was initially installed at perl5-5.20.3_8 and has been upgraded through several versions to 5.24.1.
Since upgrading perl from 5.20.3_15 to 5.24.1.r4_1 all upgrades to packages that include perl as a dependency (e.g. curl) install perl5-5.20.3_15 as a new package.
Can someone tell me what to change to correct this?

TIA,
JJ
 
When you performed those updates did you also pay attention to /usr/ports/UPDATING and/or pkg-updating(8)?

Also: are you sure you never mixed binary packages with building ports yourself? And to add to this: ever messed with /etc/pkg/ yourself? Specifically FreeBSD.conf but is it possible that you mixed repositories?

(edit)

The reason why I ask all this is simple: I don't think it's a package dependency which is causing all this. When I try to install a binary Curl package onto a pristine FreeBSD installation then Perl doesn't get pulled in at all.
 
The default Perl should be 5.24 so all official packages should be depending on 5.24. Can you try and find out which package pulls in 5.20? I update my servers regularly and never had any issues with Perl. Typically pkg(8) knows what to do. It wasn't an issue with 5.18 -> 5.20, and 5.20 to 5.24. I think I even started with older versions.
 
ShelLuser
When updating perl to 5.24 I checked /usr/ports/UPDATING. The only relevant portion of the file I could find was:
Code:
20161103:
  AFFECTS: users of lang/perl5*
  AUTHOR: mat@FreeBSD.org

  The default Perl version has been switched to Perl 5.24.  If you are using
  binary packages to upgrade your system, you do not have anything to do, pkg
  upgrade will do the right thing.

I had one problem when I did my original install. I needed to use MySQL 5.7 but also needed p5-DBD-mysql. However, installing p5-DBD-mysql would deinstall MySQL 5.7 and install MySQL 5.6 instead. I eventually installed from cpan cpan DBD::mysql instead.

WRT /etc/pkg/ I had never looked at the directory prior to today. FreeBSD.conf has a date/time stamp of when I did a full upgrade of all installed packages.

Also, I don't understand why a binary curl package would pull perl. Checking FreshPorts, it is listed as a build dependency only.

SirDice
Code:
# pkg upgrade -n curl
Updating FreeBSD repository catalogue...
Fetching meta.txz: . done
Fetching packagesite.txz: .......... done
Processing entries: .......... done
FreeBSD repository update completed. 26278 packages processed.
All repositories are up to date.
The following 3 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        perl5.20: 5.20.3_15

Installed packages to be UPGRADED:
        curl: 7.53.1_1 -> 7.54.0
        ca_root_nss: 3.30.1 -> 3.30.2

Number of packages to be installed: 1
Number of packages to be upgraded: 2

The process will require 49 MiB more space.
15 MiB to be downloaded.

# pkg upgrade -ng mysql57*
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 3 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        perl5.20: 5.20.3_15

Installed packages to be UPGRADED:
        mysql57-client: 5.7.17_2 -> 5.7.18
        mysql57-server: 5.7.17_4 -> 5.7.18

Number of packages to be installed: 1
Number of packages to be upgraded: 2

The process will require 49 MiB more space.
28 MiB to be downloaded.
#

Thanks to both of you for the responses.
JJ
 
Thanks to both of you for the responses.
You're welcome.

So here's the thing: your conclusion is wrong. This is not necessarily ftp/curl doing this. When you install a binary package then the whole system gets reviewed and other dependencies or issues also get sorted out. Last time I tried to install a binary package on my LAN server it started out by wanting to remove a ton or so installed packages for reasons I still don't fully grasp (never bothered to look into that).

I also tested this on a fresh install I keep around for testing purposes (VirtualBox) and if you install Curl there then Perl does not get pulled in as well.

So there's something else which is causing all this.

(edit)

You may want to look into DEFAULT_VERSIONS which is used in /etc/make.conf. The option is used to specify that you want to use a specific version of a port on your system. From the top of my head (I am not fully sure at the time of writing, I will update my post later if needed): but as far as I recall this also includes MySQL.

However... I also get the impression that you are indeed mixing building ports together with installing binary packages, and that is usually a bad combination every time. That too can cause issues.
 
You may want to look into DEFAULT_VERSIONS which is used in /etc/make.conf. The option is used to specify that you want to use a specific version of a port on your system. From the top of my head (I am not fully sure at the time of writing, I will update my post later if needed): but as far as I recall this also includes MySQL.
You are correct:
Code:
DEFAULT_VERSIONS= mysql=5.7
Note however that this only works for building ports. You cannot change the dependencies of existing packages.
 
So here's the thing: your conclusion is wrong. This is not necessarily ftp/curl doing this. When you install a binary package then the whole system gets reviewed and other dependencies or issues also get sorted out.

Thanks for that explanation. I typically update only those packages that have notices of security vulnerabilities. So the explanation prompts the obvious question - how can I figure out which package is requiring the reload of perl 5.20?

I looked at /etc/make.conf and DEFAULT_VERSIONS when I first started to research the problem. But, as SirDice noted, it is only for building ports and not to change package dependencies.

You are correct about building ports. Two of the applications I use, serviio and megacli, do not have packages so I built them from ports. AFAIK neither of them use perl in any way.

When I installed DBD::mysql originally perl 5.20 was installed and was used by the cpan install for testing. After upgrading to perl 5.24, DBD::mysql was updated from v4.033 to v4.041 and perl 5.24 was used by the cpan install testing. Since it was only for test runs, I would not think it would have any effect on dependencies.
 
Two of the applications I use, serviio and megacli, do not have packages so I built them from ports.
Code:
macron:/usr/ports/net/serviio $ make all-depends-list | grep perl
/usr/ports/lang/perl5.24
macron:/usr/ports/net/serviio $ cd ../../sysutils/megacli
macron:/usr/ports/sysutils/megacli $ make all-depends-list | grep perl
macron:/usr/ports/sysutils/megacli $
Also, when you mention cpan do you mean to say that you actually used /usr/local/sbin/cpan to install extra Perl modules? That too could have its effects I think, though I'm not too sure how much it could stirr things up. If you need DBS::mysql then the proper way is to install databases/p5-DBD-mysql.

Even so, despite all that, it is odd either way because the default Perl version has been set to 5.24 since somewhere in 2016 already. So to my knowledge even binary packages wouldn't rely on older versions anymore.
 
So to my knowledge even binary packages wouldn't rely on older versions anymore.
Indeed, I double checked this at the start of the thread. There was a possibility the latest branch may have had a newer version than the quarterly branches. But the default Perl version changed quite some time ago so the quarterly and latest branches have the same version.
 
Code:
Also, when you mention [file]cpan[/file] do you mean to say that you actually
used [file]/usr/local/sbin/cpan[/file] to install extra Perl modules? That too could
have its effects I think, though I'm not too sure how much it could stirr
things up.If you need [file]DBS::mysql[/file] then the proper way is to install
[port]databases/p5-DBD-mysql[/port].


Yes - I used /usr/local/sbin/cpan to install DBD::mysql.

I had installed:
Code:
#pkg install -g mysql57*
#pkg install  p5-DBI
but when I tried to install DBD::mysql it removed mysql57.
Code:
#pkg install  p5-DBD-mysql
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
   p5-DBD-mysql: 4.033
   mysql56-client: 5.6.27

The process will require 45 MiB more space.
2 MiB to be downloaded.

Proceed with this action? [y/N]:y
Fetching p5-DBD-mysql-4.033.txz: .......... done
Fetching mysql56-client-5.6.27.txz: .......... done
Checking integrity... done (1 conflicting)
Checking integrity... done (0 conflicting)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
The following 4 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
   mysql57-server-5.7.10_3
   mysql57-client-5.7.10_4

New packages to be INSTALLED:
   mysql56-client: 5.6.27
   p5-DBD-mysql: 4.033

The operation will free 148 MiB.

Proceed with this action? [y/N]:
[1/4] Deinstalling mysql57-client-5.7.10_4...
[1/4] Deleting files for mysql57-client-5.7.10_4: .......... done
[2/4] Deinstalling mysql57-server-5.7.10_3...
==> You should manually remove the "mysql" user.
[2/4] Deleting files for mysql57-server-5.7.10_3: .
mysql57-server-5.7.10_3: missing file /usr/local/etc/rc.d/mysql-server
[2/4] Deleting files for mysql57-server-5.7.10_3............ done
[3/4] Installing mysql56-client-5.6.27...
[3/4] Extracting mysql56-client-5.6.27: .......... done
[4/4] Installing p5-DBD-mysql-4.033...
[4/4] Extracting p5-DBD-mysql-4.033: .......... done

Reinstalling mysql57 server would simply remove DBD::mysql and the 5.6 client.
Code:
#pkg install  mysql57-server
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
   mysql57-server: 5.7.10_3
   mysql57-client: 5.7.10_4

The process will require 193 MiB more space.
13 MiB to be downloaded.

Proceed with this action? [y/N]:y
Fetching mysql57-server-5.7.10_3.txz: .......... done
Checking integrity... done (1 conflicting)
Checking integrity... done (0 conflicting)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
The following 4 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
   p5-DBD-mysql-4.033
   mysql56-client-5.6.27

New packages to be INSTALLED:
   mysql57-client: 5.7.10_4
   mysql57-server: 5.7.10_3

The process will require 148 MiB more space.

Proceed with this action? [y/N]:y
[1/4] Deinstalling p5-DBD-mysql-4.033...
[1/4] Deleting files for p5-DBD-mysql-4.033: .......... done
[2/4] Deinstalling mysql56-client-5.6.27...
[2/4] Deleting files for mysql56-client-5.6.27: .......... done
[3/4] Installing mysql57-client-5.7.10_4...
[3/4] Extracting mysql57-client-5.7.10_4: .......... done
[4/4] Installing mysql57-server-5.7.10_3...
===> Creating users and/or groups.
Using existing group 'mysql'.
Using existing user 'mysql'.
[4/4] Extracting mysql57-server-5.7.10_3: .......... done

My work around was to use /usr/local/sbin/cpan to install DBD::mysql.
 
The MySQL behavior is intended. MySQL 5.6 is currently the default version, so all binary packages depend on that. That's the main caveat with using binary packages: everything uses default settings and you can't really deviate from that. Well, you can since you did, but that could cause more issues in the longer run. For example when you want to install certain packages which also requires databases/p5-DBD-mysql.

But back to your question and your issue... Try: # pkg check -dn. That should clear something up here.
 
But back to your question and your issue... Try: # pkg check -dn.

Thanks for that. It identified the packages that were requiring the reinstall of perl 5.20. The problem actually had nothing to do with cpan and the install of DBD::mysql or the programs that I had installed from ports.

As you pointed out, packages reference the default version of a program at the time they are created. After a server is put into production, I typically upgrade only those packages that receive security vulnerability notices (and whichever packages are automatically upgraded because of them). Several packages were installed originally that required perl 5.20 and had not matched either of the upgrade criteria. Running a package upgrade for that list eliminated the problem.
 
I'm happy to hear that we solved the issue. One last thing...

I typically upgrade only those packages that receive security vulnerability notices (and whichever packages are automatically upgraded because of them).
Yeah, that is not a good strategy and you need to be careful with that. This was just a minor setback, but that strategy can really get you into some serious issues.

Just because of those dependencies you should always perform a full update unless you have specific reasons not to upgrade a certain packages.
 
Back
Top