Perl upgrade problem

patpro

patpro

Hi,

I'm running a FreeBSD 10.1 server, with lots of services (mail, web, db…). I used to have perl5-5.18 installed. Unfortunately I tried to upgrade to perl5-5.20 (the new default).
I've read /usr/ports/UPDATING but found no real help.

It started with the upgrade of MySQL server and client from 5.5 to 5.6: a dependency (p5-DBD-mysql) caused perl5-5.18 to be upgraded and perl5-5.20 to be installed. At this time, Amavisd-new would not start anymore, meaning my antispam is broken, and I could not accept emails.

I've found in /usr/ports/UPDATING that the name of my old perl package was not so good: perl5.18-5.18.4_17 and required renaming, so I used:

Code: 
pkg delete perl5-5.20.3_8
pkg set -n perl5.18:perl5

I've deleted MySQL server and p5-DBD-mysql too, and performed an upgrade of Perl:

Code: 
(syslog) perl5 upgraded: 5.18.4_17 -> 5.20.3_8

Amavisd-new still wont start (failed dependencies).
So I try to reinstall one p5 package: I'm upgrading p5-Archive-Zip. This upgrade causes perl5.18-5.18.4_17 to be re-installed.
At this point, I re-delete perl5-5.20, and try to start Amavisd-new: fail.

After looking online for a workaround, I'm adding this line to /etc/make.conf:
Code: 
DEFAULT_VERSIONS+=    perl5=5.20

and launch:
Code: 
pkg set -o lang/perl5.18:lang/perl5.20
portmaster p5-

Every installed p5-* port is updated or re-installed, and Amavisd-new starts successfully.
Since then, I've commented out DEFAULT_VERSIONS in /etc/make.conf

Unfortunately, I'm pretty sure I've broken something in pkg's DB: I can't use pkg to install or update software that depends on Perl, because it always want to reinstall perl5.18.

for example:
Code: 
# pkg install munin-common
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:
    perl5.18: 5.18.4_17

Installed packages to be UPGRADED:
    munin-common: 2.0.25_1 -> 2.0.25_2


I'm a bit lost here, any help greatly appreciated.
 
And by the way, as far as I can tell, the pkg DB looks ok:
pkg-db.png


I don't understand why pkg tries to install perl5-5.18 when I want to upgrade munin-common (or any other pkg which depends on Perl).
 
youngunix said:
reinstall perl5-5.20
Click to expand...
I wonder how you do that, in fact. Am I supposed to remove Perl, hence removing half my ports and pkg, and then reinstall everything from scratch, remembering what was carefully tuned and compiled and what was installed using just pkg?

removing Perl, will of course delete perl5 and every p5-*, but it will also delete those:
Code: 
    apache24-2.4.16
    zfs-stats-1.2.2_1
    automake-1.15
    munin-node-2.0.25_4
    opendkim-2.10.3_1
    logcheck-1.3.17
    amavisd-new-2.10.1_1,1
    w3m-0.5.3_4
    autoconf-2.69
    aspell-0.60.6.1_5
    razor-agents-2.84_1
    intltool-0.50.2_1
    mosh-1.2.5
    mime-construct-1.11_2
    munin-common-2.0.25_1
    mysql56-server-5.6.27
    glib-2.42.2
    spamassassin-3.4.1_5
    clamav-unofficial-sigs-3.7.2_2
    pure-ftpd-1.0.40
    ap24-mod_fastcgi-2.4.7_1
    roundcube-1.1.3_1,1
    mod_php56-5.6.14
    ap24-mod_python35-3.5.0_1
    php56-pspell-5.6.14
    cairo-1.12.18_1,2
    avahi-app-0.6.31_3
    gobject-introspection-1.42.0
    avahi-libdns-0.6.31_1
    dbus-glib-0.104
    cups-client-2.0.3_2
    cups-image-2.0.3_2
    ghostscript9-base-9.06_11
    GraphicsMagick-1.3.20_4,1

mod_php56 is installed via ports, as is munin-node, opendkim, p5-IO-Socket-SSL, p5-Net-Server, p5-libwww, pure-ftpd, roundcube and spamassassin.
 
Your ports settings are saved between builds, you can find them in /var/db/ports/. Unless you remove them or run something like make rmconfig-recursive your options will be saved.
 
SirDice, I'm perfectly aware of that, I've even designed a shell script to help me list differences between my options and those "by default" (see https://forums.freebsd.org/threads/...t-and-custom-ports-options.46228/#post-290575 ).

Uninstalling and reinstalling perl is a real pain and is abnormally problematic, causing a big downtime for many services (web, mail…). The real question is why would munin-common (and many other) require perl5-5.18 when everything in pkg DB seems to point at perl5-5.20.
 
It doesn't. It'll use whatever is set as default. After upgrading Perl 5.18 to 5.20 you will need to rebuild everything that depends on Perl to make sure the dependencies are set correctly.
 
It does. Or at least it did, see the last CODE block of my first post: perl5-5.20 is installed, I try to upgrade munin-common, then pkg tries to install perl5-5.18.
I've deleted munin-common and installed munin-node again, using only pkg: it was ok. I just still don't get why an upgrade using pkg install munin-common would want perl5-5.18 when a pkg delete followed by a pkg install would run fine.

Code: 
# pkg delete munin-common
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 2 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
    munin-common-2.0.25_1
    munin-node-2.0.25_4

The operation will free 963 KiB.

Proceed with deinstalling packages? [y/N]: y
../..

# pkg install munin-node
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
The following 5 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
    munin-node: 2.0.25_4
    munin-common: 2.0.25_2
    p5-Net-SNMP: 6.0.1_1
    p5-Crypt-DES: 2.07_1
    p5-Crypt-CBC: 2.33_1

The process will require 1 MiB more space.
398 KiB to be downloaded.

Proceed with this action? [y/N]: y
 
To delete a package without deleting everything that depends on it, use pkg delete -f. Of course, that leaves all of those other packages with missing dependencies, so that has to be fixed.
 
and the answer is...
You can't have your cake, and eat it too. meaning; you can't use pkg() and ports(). Well, you can, but not without a great deal of accounting, and even then, you'll likely get bitten somewhere along the line. You used to be able to do both with the old version of pkg. But even then, you still needed to be careful. So, as a rule, unless you are very, very careful. You will want to either use pkg(), or ports(). But not both -- sorry :-/

Hope this helps.

--Chris
 
Situation is even worse: with the latest pkg version (on FreeBSD 10.1), even a locked package is updated...
And the increasing complexity involved in using both pkg and ports is a huge deterrent for potential FreeBSD users who build general purposes servers (web/php/python/sql/email/mailing lists/ftp...) -> you want dovecot2 compiled into your postfix, well, use only ports for your software install/update. A bit hard to promote.
 
While it's not for me. I didn't want to sound like I was disparaging pkg(). Frankly; if you come from Linux, or are new to FreeBSD, pkg(), as well as FreeBSD update, really lowers the bar to entry. I'm just too picky "type A" to let someone || something else, decide what options are best for me, and my situation. So it's ports() all the way, for me. :)

--Chris
 
For most part Linux distros don't even offer you the flexibility we have with ports(7) forcing you to use "one size fits all" packages. These dependency gotchas with FreeBSD packages are the price you pay for that flexibility.
 
Chris_H said:
While it's not for me. I didn't want to sound like I was disparaging pkg(). Frankly; if you come from Linux, or are new to FreeBSD, pkg(), as well as FreeBSD update, really lowers the bar to entry. I'm just too picky "type A" to let someone || something else, decide what options are best for me, and my situation. So it's ports() all the way, for me. :)
Click to expand...

ports are ok, when you can spend the time (done that for more than 12 years). But pkg really offers a quick way with less clutter (build dependencies that take ages to compile, for example). Unfortunately for very serious reason you'll end up needing extra/less options in some software. This ports/pkg duality that I was successfully handling for years now breaks in my face. I can't imagine a newbie getting into this mess.
Poudriere might be a solution, but it's probably too much hassle for a single server. Might come handy @work where I have 5 servers and about 12 jails on one of them.

You're right about accounting, I must find a way to properly record what comes from ports or pkg. With a good work flow, I could just be able to pkg upgrade and re-install manually every ports I need. Well, just in case I want to upgrade everything, which is quite rare.
 
Well pkg() does offer some clues, as to exactly what/where any installed ports came from, how they were installed -- even what dependencies they have. You could probably use the output from it, to help with "accounting".
OTOH, as for ports() being cumbersome, and time consuming. Up until just recently I had a single box dedicated to producing packages for all my other boxes/servers. I ran "traditional" jails on it. Never much cared for ports-mgmt/poudriere. Don't like being forced into someone else' idea of the perfect workflow. However, I was recently introduced to ports-mgmt/synth. I'll probably never use that package manufacturing box again. You can pretty much set it, and forget it. My experience has been quite well with it. Highly recommend it to anyone who's ports(7) oriented. :)

--Chris
 
You must log in or register to reply here.
Back
Top