My DragonFly 3.6 upgrade adventure

Here’s how my upgrade from DragonFly 3.4 to 3.6 for this server went.

The system install went normally.  I rebooted before performing ‘make upgrade’, as noted in UPGRADING and elsewhere.

I already have dports installed, so a binary upgrade should be possible.  I had heard of people with older version of pkg, having trouble getting it to notice upgrades.  I rebuilt pkg, and ran ‘pkg upgrade’.  A number of the updates coredumped.  Here’s one example:

[156/160] Upgrading gtk2 from 2.24.19 to 2.24.19_2...Segmentation fault 
(core dumped)

After the upgrade, I had two problems: PHP wasn’t working for the website, and some programs would segfault.

The random segfault was fixable by forcing a binary upgrade of all packages.  Since there were some programs on the system that were still new enough that the version number was the same as on the remote repository, pkg didn’t upgrade them.  Those packages were linked against old versions of system libraries that predated the locale changes in DragonFly 3.6, so they’d crash.  Forcing the update for all packages fixed the issue.

The other problem, PHP on the web server, is not new to me.  The binary package for PHP does not include the module for Apache.  The solution is to build from source with that option selected.  I understand that pkg is destined to support (some?) port options in the future.  There’s also an immediate workaround for locking it.

However, the port would not build because of a security issue.  The binary package installed without any warning.  This, I am told, will change to pkg giving you the option to install if you are aware of the security problem, and whether it really affects you.  (which is just what I want, yay!)

Anyway, other than the system changes biting me because I didn’t realize some packages weren’t updated, it went very quickly.  That is the reason for binary updates through pkg, or at least a major one.

3 Replies to “My DragonFly 3.6 upgrade adventure”

  1. in case of major upgrade, pkg upgrade -f is highly recommanded.
    I do plan to automate it so -f is not required anymore but we are not there yet.

  2. If I had been thinking a little harder about it, I would have done -f first. I was mentally assuming all the packages would have new versions too. When there is an ABI change, everything has to go.

  3. FreeBSD 9.2 pkg was a rough upgrade too. I had to get some keys out of svn, create some empty (!) directories in some obscure places, otherwise the package database wouldn’t update.

Comments are closed.